On Wed, 4 Feb 2026 at 20:48, Patrick Palka <[email protected]> wrote: > > 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.
By default it only runs -std=gnu++20, or for tests which have a newer effective target, they run with the minimum required -std and also -std=gnu++26. They'll only run for -std=gnu++11 if that's explicitly in v3_std_list or GLIBCXX_TESTSUITE_STDS. > > I didn't know the PCH files are also installed and available to users > though. >
