On Wed, 4 Feb 2026, Jakub Jelinek wrote:
> On Wed, Feb 04, 2026 at 03:48:36PM -0500, Patrick Palka wrote:
> > 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.
>
> Is PCH actually mapped or is the slow down due to parsing of bits/stdc++.h ?
> I think the PCH file is created just for the default options (so
> -std=gnu++20), so all tests using -std=gnu++2{3,6} or -std=c++* or
> -std=gnu++[19]* will be slower if -include bits/stdc++.h is used when
> compiling them.
Good point. I tested compiling (checking + non-bootstrapped) some tests by hand
libstdc++-v3/testsuite/23_containers/vector/40192.cc (small)
libstdc++-v3/testsuite/std/ranges/adaptors/join.cc (mediumish)
libstdc++-v3/testsuite/28_regex/algorithms/regex_search/ecma/greedy.cc (large)
with "-O2 -g -c" vs "-O2 -g -c -include O2g" (where O2g.gch is copied
from the build directory and then all PCH files are removed).
libstdc++-v3/testsuite/23_containers/vector/40192.cc:
0.18s (non-PCH) vs 0.75s (PCH)
peak memory use is 70MB vs 250MB
libstdc++-v3/testsuite/std/ranges/adaptors/join.cc:
3s PCH vs 3.35s
220MB vs 380MB
libstdc++-v3/testsuite/28_regex/algorithms/regex_search/ecma/greedy.cc:
8s vs 8.35s
160MB vs 260MB
So seems using PCH is worse in each case (and it indeed works on
x86_64)
