On Wed, 4 Feb 2026, Jakub Jelinek wrote: > On Wed, Feb 04, 2026 at 11:35:50AM -0500, Patrick Palka wrote: > > I didn't know PCH'd stdc++.h is so big! I'll continue using > > --disable-libstdcxx-pch during development to avoid wearing down my > > SSD (and avoid the slowdown of make having to rebuild the PCH after > > every library header change). > > > > I wonder whether using PCH'd stdc++.h is still faster anymore given how > > big the standard library is nowadays. Is the overhead of deserializing > > the entire library AST, keeping it in memory, slowing down parts of the > > front end that are >=linear in the size of the TU (including GC which is > > frequent in checking mode) less than the overhead of not using PCH > > and just parsing the subset of the library that's actually needed, for > > our average libstdc++ testcase? > > I think for x86_64 PCH is not used anyway due to some CET related mismatch > during testing but I could be wrong.
If the PCH file is for some reason unusable would that mean every libstdc++ test falls back to parsing bits/stdc++.h instead of mapping it in? Out of curiosity I just timed running a subset of the libstdc++ tests with and without --disable-libstdcxx-pch (with checking + non-bootstrap on x86_64) and it seems the PCH stuff slows things down! The vector tests finish in roughly half the time without PCH, and the ranges + regex tests in roughly 70% of the time. IIUC we use PCH in the libstdc++ testsuite to speed it up, but according to this experiment it's having the opposite effect nowadays. > > If you don't GC, then just mapping it in should be quite fast and even > if there is GC, while the first GC will take longer, it should kill > everything not needed and get back to the normal size. We'll clear caches after the first GC, but it'll still mean that all the bindings and definitions of e.g. <regex>, <format> and <chrono> live in memory even for the tiniest unit test for say vector or string. > > Anyway, I wonder why we build the -O2ggnu++0x.gch files these days: > -rw-r--r--. 1 jakub jakub 213581873 Feb 3 23:07 > ./x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/extc++.h.gch/O2g.gch > -rw-r--r--. 1 jakub jakub 166490263 Feb 3 23:06 > ./x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch > -rw-r--r--. 1 jakub jakub 101706811 Feb 3 23:06 > ./x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch > -rw-r--r--. 1 jakub jakub 172619402 Feb 3 23:07 > ./x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch > -rw-r--r--. 1 jakub jakub 214381431 Feb 3 23:05 > ./x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/extc++.h.gch/O2g.gch > -rw-r--r--. 1 jakub jakub 167179995 Feb 3 23:04 > ./x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch > -rw-r--r--. 1 jakub jakub 102411920 Feb 3 23:04 > ./x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch > -rw-r--r--. 1 jakub jakub 173411402 Feb 3 23:05 > ./x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch > That made sense when -std=gnu++98 has been the default, when -std=gnu++11 > has been the default no sense at all and even now, I think if we want to > include something other than the default -std=gnu++20, it would be > -std=gnu++17, not -std=gnu++0x, I hope most of C++ projects aren't stuck > in C++11 days. The libstdc++ testsuite nowadays runs every test multiple times (for each applicable -std=) so I'd assume the gnu++11 PCH files are still used by the testsuite. I didn't know the PCH files are also installed and available to users though.
