https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934
--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #26) > Note, the code to emit that relocation table isn't for free, besides that > ~3% growth of the *.gch files it also slows down the PCH generation, e.g. > for stdc++.h at -O2 -g on my box from ~3.45s to ~4.13s, so some 20%, I bet > mainly to qsort the array of ~2.5 million pointers. the one CS problem indirection cannot solve is having too many pointers ;). Do you have a feel for what the growth in time is for the whole parse+output? (we assume that PCH remains useful so long as the read-in is quicker than that, right?) > But upon PCH restore it shouldn't be noticeable, it is one size_t fread and > one fseek when no relocation is needed.
