From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 1F083385C313 for ; Fri, 24 Jun 2022 06:20:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F083385C313 Received: by mail-wr1-x429.google.com with SMTP id i10so1801082wrc.0 for ; Thu, 23 Jun 2022 23:20:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4vL2Iq9O6gyKFvh1xv4NUprjb1LtXdmZaoJrg6pl6/U=; b=qlxDEbg5POhhd34gJe3cbk2L7+obyj1FWxL7Vcvnf2Omgy31au/4fZ6Oaa0RZcUiL8 huIrLWtn1j2jzsotKssbuT11y1SgbAEKAfNbNPviTjvsLjoRQqSSqmd8xgmIcOgsHPxQ ntLSNKQn6zqO0UIGj4BVviGTo3QSRHEaWdssusvTqF0LZKrzIq6Ubmb5Tnq6wTwW3mwN zq4TTpKVR9Rgr03Z76IhQEIedpvBSdXsRnuAA2oS6HVjDKdPrDiveZ7PGbb6Ixe6WTK2 0THubhrMkBvhY+fpSufbryZbAr0uPbvyGAKTYW8fFXuZNPV+I4eHxHd5qdplcj9/OgNL N1QQ== X-Gm-Message-State: AJIora++PHtWuV52GRp4WS/FsVqOVVLnpXAhxwsD0gzKDXFaA+4fH2z6 7V1QihBoBu1MAe8RkIeAaS+7AI3Pts3TuvrwkNQ= X-Google-Smtp-Source: AGRyM1vND5e8HMmLPIlUU/8WYSWbqvwMs0NKrQm2KdfnZlGO7IEY2FCi+FVFd6e8xoD2Pq42LbxaxAbxVE4dLQQ+yk4= X-Received: by 2002:a05:6000:184c:b0:21b:b6ac:8cb6 with SMTP id c12-20020a056000184c00b0021bb6ac8cb6mr824348wri.154.1656051640897; Thu, 23 Jun 2022 23:20:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 24 Jun 2022 07:20:29 +0100 Message-ID: Subject: Re: First-time contributor -- speeding up `std::unique_ptr` compilation To: mail@vittorioromeo.com Cc: "libstdc++" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2022 06:20:44 -0000 On Fri, 24 Jun 2022, 01:19 , 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 `` 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 '' > 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.