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

[Dmitry Samersoff]

Volker,

Thank you for the numbers.

I had a goal to get my own opinion about PCH and JPRT. And I think we
can safely turn PCH off for all JPRT builds.

-Dmitry

On 2015-05-08 20:04, Volker Simonis wrote:
> 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.


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.