public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: <mail@vittorioromeo.com>
To: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>
Subject: First-time contributor -- speeding up `std::unique_ptr` compilation
Date: Fri, 24 Jun 2022 00:19:26 +0000	[thread overview]
Message-ID: <DU0P189MB2067C41E523C9CDA9EF08285E1B49@DU0P189MB2067.EURP189.PROD.OUTLOOK.COM> (raw)

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.
  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.

Thanks.


Vittorio Romeo
https://vittorioromeo.com

             reply	other threads:[~2022-06-24  0:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-24  0:19 mail [this message]
2022-06-24  6:20 ` Jonathan Wakely
2022-06-24  7:22   ` Jonathan Wakely
2022-06-25 12:45     ` Vittorio Romeo
2022-07-25 21:34       ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DU0P189MB2067C41E523C9CDA9EF08285E1B49@DU0P189MB2067.EURP189.PROD.OUTLOOK.COM \
    --to=mail@vittorioromeo.com \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).