We REALLY nead a NON-PCH build in JPRT NOW!

Volker Simonis volker.simonis at gmail.com
Fri May 8 17:04:07 UTC 2015


On Thu, Apr 23, 2015 at 7:13 PM, Dmitry Samersoff
<dmitry.samersoff at oracle.com> wrote:
> Everyone,
>
> FYI,
>
> Did small benchmark for entire JDK clean build on my laptop
> - linux-xfs, core I5, 8G, SSD, idle.
>
> As expected, PCH doesn't really affects a clean build.
>
> Numbers below:
>
> ** ccache,  no pch, no javac
>
> Finished building Java(TM) for target 'default'
> 12079.395u 320.784s 58:20.54 354.2%     0+0k 0+0io 56pf+0w
>
> ** no ccache, pch, no javac
>
> Finished building Java(TM) for target 'default'
> 12847.053u 340.212s 59:07.99 371.6%     0+0k 0+0io 0pf+0w
>
> ** no ccache, no pch, no javac
>
> Finished building Java(TM) for target 'default'
> 12493.502u 298.802s 54:36.23 390.4%     0+0k 0+0io 17pf+0w
>

Hi Dmitry,

from my experience, PCH helps most if you have a slow file system. You
have measured with a SSD which reduces the gains of PCH.

Also, because currently only the HotSpot build supports PCH, comparing
build numbers of a complete JDK builds is a little misleading because
the HotSpot build is only a small part of the complete build.

Doing a 'make hotspot-only JOBS=8' build on Linux/ppc64 with the
sources on a NFS share gives the following results:

with PCH:
real    3m6.580s
user    6m44.423s
sys    2m5.348s

without PCH:
real    3m48.296s
user    12m20.448s
sys    1m41.423s

As you can see, the non-PCH build consumes nearly twice as much user
time as the PCH build, so the PCH build can still be useful in certain
environments.

Regards,
Volker

> -Dmitry
>
>
>
> On 2015-04-23 18:19, Coleen Phillimore wrote:
>>
>> On 4/23/15, 3:42 AM, Andrew Haley wrote:
>>> On 23/04/15 00:42, Coleen Phillimore wrote:
>>>> On 4/22/15, 3:57 AM, Andrew Haley wrote:
>>>>> On 22/04/15 03:01, Daniel D. Daugherty wrote:
>>>>>> Personally, I like the idea of not adding any more new JPRT targets
>>>>>> and reconfiguring to have fastdebug and/or debug builds run as
>>>>>> non-PCH...
>>>>>> It's a much simpler policy to explain:
>>>>>>
>>>>>>        If we support PCH builds with a particular toolset then product
>>>>>>        builds default to PCH and non-product builds default to no-PCH.
>>>>> But the debug builds are used in development all the time.  It's
>>>>> these that really benefit from PCH.
>>>> I feel like PCH makes development slower.  I change a header file and
>>>> all the files in the system are recompiled because it happens to be in
>>>> the precompiled file.
>>> But that'll happen anyway if the change you made is to one of the common
>>> headers.  I can't see that it makes any difference.
>>>
>>> Maybe it depends on what you're working on?
>>
>> linkResolver.hpp - maybe it's one that doesn't belong in precompiled.hpp
>> but I suspect a lot of files fall into that category.  If PCH doesn't
>> really make builds that much faster, why have it?  I'm planning to
>> change my script that calls configure to not use precompiled headers.
>>
>> Thanks,
>> Coleen
>>
>>>
>>> Andrew.
>>>
>>
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.


More information about the hotspot-dev mailing list