[v3] multi-pch

[Benjamin Kosnik]

Here's some testsuite timings with various PCH configurations.

g++-version 20060625

-include bits/stdc++.h
1467.587u 200.580s 29:09.03 95.3%       0+0k 0+0io 0pf+0w
1493.265u 199.392s 28:53.54 97.6%       0+0k 0+0io 0pf+0w

-include bits/stdtr1c++.h
1360.873u 214.129s 26:38.08 98.5%       0+0k 0+0io 0pf+0w
1363.005u 212.405s 26:32.25 98.9%       0+0k 0+0io 0pf+0w

-include bits/extc++.h
1407.479u 233.518s 28:23.50 96.3%       0+0k 0+0io 0pf+0w
1400.851u 233.798s 27:30.87 99.0%       0+0k 0+0io 0pf+0w

Where
stdc++
stdc++ + tr1 = stdtr1c++
stdc++ + tr1 + ext = extc++

aka, "the bigger blob" design. See attached patch. 

>From this, it seems as if moving to std + TR1 as the PCH of choice
provides real benefits, but precompiling every interface (ie std + TR1
+ ext) does not.

So, I'm thinking of checking this in, but am going to wait for comments
for a bit.

It looks like pb_ds tests are compilation bound for a
substantial time. I've had positive experiences with pre-compiling
parts of pb_ds before... therefore, I'm going to try another approach,
which is to make a pb_ds PCH for build regression testing only. In
particular, want to lower compilation speed for pb_ds/regression/*.cc
tests (say hash_data_map_rand.cc).

This is the "specialized blob" approach, and is still testing...

tested x86/linux

-benjamin

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: p.20060628-1
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20060629/fd1a276a/attachment.ksh>