Jonathan Wakely <jwak...@redhat.com> writes: > On Sat, 29 Apr 2023 at 11:24, Arsen Arsenović via Libstdc++ < > libstd...@gcc.gnu.org> wrote: > >> libstdc++-v3/ChangeLog: >> >> * libsupc++/typeinfo: Switch to bits/version.h for >> __cpp_lib_constexpr_typeinfo. >> >> > Does this change have an impact on compilation speed? > With this change we'll be re-including bits/version.h multiple times in > most compilations, and unlike other headers the preprocessor can't optimize > away the second and subsequent times its' included, because the header > isn't idempotent. > It will only affect the preprocessing phase, which is a fraction of the > time taken by template instantiation and middle end optimizations, but I'd > like to know it's not *too* expensive before committing to this approach. >
Whoops, I forgot to provide these measurements.
~/gcc/build$ time for x in $(seq 1 100); do _pfx/bin/g++ -x c++ - \
-S -o /dev/null <<< '#include <bits/stdc++.h>'; done
real 3m4.104s
user 2m53.394s
sys 0m10.132s
~/gcc/pristine-bld$ time for x in $(seq 1 100); do _pfx/bin/g++ \
-x c++ - -S -o /dev/null \
<<< '#include <bits/stdc++.h>'; done
real 2m56.430s
user 2m46.898s
sys 0m8.967s
The top is a build of gcc with (a rebase of) this patchset, and the
bottom is the merge base. The configuration for both was:
../configure --enable-languages=c++ \
--disable-libsanitizers \
--prefix="$(pwd)/_pfx"
This should imply that the difference is minor compared to compilation
time.
Of course, for preprocessing, the difference is far more significant
(same testcase, but with -E): 0m17.248s vs 0m28.382s.
This seems okay to me.
--
Arsen Arsenović
signature.asc
Description: PGP signature
