Re: precompiled headers and includeDB*

Hi Tom,

Using precompiled headers does help a lot to reduce hotspot compilation 
time.
The can be clearly observed if you compare with compilation time using 
Sun Studio that we use for Solaris builds.
In the mean time we continue to convince sun studio folks to improve 
precompiled header support. The way it is done now it will not help much 
hotspot compilation.

Now to you points;
Looking at http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
there is a restriction "Only one precompiled header can be used in a 
particular compilation"
So we can't have many small precompiled files

Regards,

Ivan.

tom fogal wrote:
>  <200703151144.45721.lists@...>Kurt Miller writes:
>> The use of precompiled headers obscures problems with
>> the includeDB* files and they have become out of date.
> [snip]
>> I could use some guidance at this point. Do the patches
>> below look correct so far?
> [snip]
> 
> While we're on the subject, is there a compelling reason for the
> includeDB system in general?  I guess I don't really understand that
> aspect of the build system very well.  It exists because of a potential
> performance gain in build times through the use of precompiled headers,
> correct?
> 
> As far as I know, the system uses these includeDB files and MakeDep to
> somehow build a single giant include file, which gets precompiled.
> Then all files end up including this precompiled header.
> 
> This seems like a lot of trouble to go through however, and I'm not
> convinced of the performance gain.  In this scheme, compilation of
> file.C won't have to parse its include of file.h, but it still has to
> read 1 giant precompiled header file from disk.  It would seem that
> reading + parsing a small number of includes wouldn't be that much
> slower (or maybe even faster) then just a read of one large precompiled
> header.  Unless most headers really need to get included in a
> significant portion of the JDK, which seems unlikely but possible.
> 
> So, making the unreasonable assumption that I understand things
> correctly, then dependencies && includes could be done in a more
> traditional way.  Performance would hopefully be similar, and that
> could deprecate `MakeDeps', making OpenJDK one step closer to not
> requiring a bootstrap JDK (I'm not sure if thats a reasonable eventual
> goal, but from posts it seems like that would be nice).
> 
> Thoughts / corrections to my logic?
> 
> -tom

--

-- 

Ivan Krylov
J2SE Hotspot Runtime Team
x(70)33368 (+7 812 3346368)