https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #8 from Agustín Bergé <kaballo86 at hotmail dot com> --- (In reply to Manuel López-Ibáñez from comment #7) > (In reply to Agustín Bergé from comment #6) > > Well, not necessarily, It's not `std::tuple` which is at fault, but the > > compiler (gcc and every other). Note that this issue was moved from > > libstdc++ to c++, so that's promising! > > I don't see any analysis of what the "bug" actually is. If there is a bug in > g++, you should be able to trigger it with a testcase not including <tuple>. > > On the other hand, if you want to provide an alternative implementation of > <tuple>, you should join libstc++: > https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html This issue started targeting libstdc++, and later someone reassigned it to c++. The recursive tuple implementation in libstdc++ causes our use of large tuples to more than double compilation time when compared to a flat implementation. Hence the inclusion of <tuple>. There is no bug, but a QoI issue that makes `std::tuple` use prohibitive for large tuples. Whether the QoI issue belongs with libc++ or g++, I am not entitled to say. The underlying issue is a g++ issue, but there are known compile-time efficient implementations of `std::tuple`. Of course, a solution in the compiler would benefit a wider audience so it would be preferable. And again, no solution would be fine as well given that this is QoI. As for a "bug" analysis (which is a requirement that I was unaware of), I haven't put this particular combination of implementation and compiler under a profiler. I have done however enough experimentation on similar code bases and the results are consistent, so while I might be off in the specific details it should still give you a strong hint of where to look. The issue boils down to name mangling and lookup: the longer the name the more memory consumption and cpu usage. For a recursive variadic implementation, instantiating a tuple of N elements with aggregated mangled length M results in the mangling of N bases with average mangled length M/2. For a flat variadic implementation, it results in the mangling of N bases of average mangled length M/N instead. As the tuple gets large and the names get long (and mangled names get very long very fast), the recursive implementation turns into a compilation time (and memory!) hog way faster than a flat implementation does. Please let me know if I can help you in any other way.
