[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-bugs
Subject:    [Bug c++/62056] Long compile times with large tuples
From:       "kaballo86 at hotmail dot com" <gcc-bugzilla () gcc ! gnu ! org>
Date:       2014-09-30 20:19:55
Message-ID: bug-62056-4-vLfRk3mQlD () http ! gcc ! gnu ! org/bugzilla/
[Download RAW message or body]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056

--- Comment #10 from Agustín Bergé <kaballo86 at hotmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #9)
> I cannot say if the libstdc++ implementation could be better

From a compile-time performance point of view it is, check the implementation
attached to this issue.

> but the way to
> prove it is simply to submit a new implementation and convince the
> maintainers that it is better with numbers. I'm sure they will be delighted
> to receive such contribution. But a draft is not enough. The new
> implementation needs to pass all testcases in the testsuite.

Such implementation and numbers were initially attached to this issue. The
draft implementation is feature complete (modulo bugs) and is implemented with
the minimal possible number of changes from the current implementation. The
entire functionality is retained, the layout is switch to left-to-right
(instead of reversed), I have not analyzed codegen.

I was directly instructed by libstdc++ developers to submit this issue, I was
told they were not aware of the poor compile-time performance of tuple. I
submitted the issue as instructed. I decided to add the proof-of-concept
implementation so that people could understand the implications by simply
replacing a header. I added the analysis of the underlying issue upon your
request.

I am not interested in pursuing this further without as much as a hint that the
compile-time performance issue would even be considered. Remember, this is QoI,
so completely ignoring this issue is a reasonable resolution. After all, this
is a known issue with known solutions (or I should say workarounds, as the
underlying issue is not addressed), and there are other concerns to keep in
mind besides compile-time performance.=
[prev in list] [next in list] [prev in thread] [next in thread]