First-time contributor -- speeding up `std::unique_ptr` compilation

[Jonathan Wakely]

On Fri, 24 Jun 2022, 01:19 , <mail@vittorioromeo.com> wrote:

> Hello everyone,
> Hope you are all doing well.
>
> I would like to begin by saying that I am terribly unfamiliar with mailing
> lists and I've always found them cumbersome to use -- I tend to do most of
> my development via GitHub PRs and Discord. Therefore, please forgive me if
> this is not the right place to discuss "how to contribute", and also
> forgive me for not being able to create a proper patch file.
>
> My goal is to generally improve the compilation speed of C++ programs
> using the standard library. In personal projects and open-source projects I
> maintain, I've achieved good results by benchmarking compilation via
> ClangBuildAnalyzer, figuring out the bottlenecks, and optimizing them.
> While working on the SFML project, I noticed that the `std::unique_ptr`
> template was taking a lot of time to be instantiated using the latest
> version of libstdc++.
>
> I investigated a bit, and figured out that the `<tuple>` include and
> `std::tuple` instantiation were the culprit. I then replaced them with a
> handmade workaround in my system libraries, recompiled SFML, and noticed
> that `std::unique_ptr`'s instantiation time became negligible as a result
> of my changes. As a side benefit, we also avoid including the '<tuple>'
> header altogether, reducing the risk of unintended transitive includes. I
> created a PR on the GCC GitHub mirror as a way to observe the diff in a
> nice interface and to discuss my changes, and to see if the maintainers
> generally think that this is a good idea. You can see the diff here:
> https://github.com/gcc-mirror/gcc/pull/67/files?diff=split&w=1
>
> In terms of rough measurements, the average instantiation time of
> `std::unique_ptr` went from 22ms to 4ms. This was measured over the entire
> SFML codebase using clang++ 14.x with the `-ftime-trace` flag, plus the
> aforementioned ClangBuildAnalyzer tool.
>
> A few questions:
>
>   1.  Is this improvement something that the libstdc++ maintainers would
> want to merge in? Of course, the changes need to be cleaned up and adapted
> to GCC's coding style.
>

No, it would be a ABI break. It would change the layout for a deleter with
the 'final' specifier.

It also looks like quite a maintenance headache "just" for improved
compilation time. The need for two implementations (with and without the
attribute) that both need to be kept ABI compatible with std::tuple doesn't
seem like a good trade off and a good use of maintainer effort.


  2.  If so, what is the easiest way to create a patch in the format that
> you are used to and test it against libstdc++'s test suite? I have never
> contributed to libstdc++ or GCC before.
>

I'll reply to this part later today.