RFR: 8283323: libharfbuzz optimization level results in extreme build times [v3]

[Magnus Ihse Bursie]

On Thu, 24 Mar 2022 07:38:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> @mrserb Phil said that we don't even use the subset part of harfbuzz.
>>> 
>>> And unless you're backing up your claim that this patch is changing runtime characteristic with data, that's just a guess, just like the initial optimization level of this library (and as most of the native libraries in the JDK... :-() was just a guess. Otoh, that we get a build time regression for these two files is a proven fact.
>>> 
>>> What is it you want to cache?
>> 
>> It is a reasonable question. Build times might seem important to a small number of developers but runtime performance is King. That's why I asked to reduce it to just the files we don't care about. 
>> Would we give up even 0.1% of hotspot GC performance on Linux to avoid 30 seconds of compile time ?
>> I doubt it. 
>> And haven't we improved compile time a lot with the parallelism ? So are we now over-optimising in the wrong place ?
>> I mean good to keep an eye on it but I mean if a previous build arch took 15 mins and now with parallelism we take 3 mins and 45 secs .. is it so bad to be back up to 4 mins for more runtime benefit ? (Numbers entirely made up)
>> There's always going to be a long pole (something that is last) and the questions are whether its understood and for a good reason and so forth. I mean we can doubtless try to improve but at some point it is diminishing returns.
>> Perhaps someone can ask gcc devs why they are so slow on this code ? Maybe there's a good reason that helps runtime or maybe they just have design issues. They may want to know.
>
>> And unless you're backing up your claim that this patch is changing runtime characteristic with data, that's just a guess, just like the initial optimization level of this library (and as most of the native libraries in the JDK... :-() was just a guess. Otoh, that we get a build time regression for these two files is a proven fact.
> 
> All java2d libraries are compiled using HIGHEST, that option was bumped to this level over time because it was proved that they affect the performance, an example the last change: https://bugs.openjdk.java.net/browse/JDK-8264846
> So I think we should check first that it does not affect performance, even if it is not used now it can be used in future version of harfbuzz.

@mrserb As Phil has stated twice, this code is not used by the JDK, so will not affect performance.

It is impossible to predict what future changes in harfbuzz will do to our performance. That will of course needed to be tested when we update harfbuzz. If it turns out that setting this optimization level is detrimental to our performance at that point of time, we'll of course do what fixes needs to be done, at that point.

@prrace The sad truth is that java.desktop-libs is at the end of the long pole, due to how different modules are interrelated. :-( That means that the compilation time for these native libraries tend to dominate the entire build time, regardless of how parallelized the rest of the build can be made. (cf. Amdahl's law) 

I'll look into once more if we can do some shenanigans to try to get around some of these dependencies, but I'm not sure it's possible.

I encourage you to report this to both upstream harfbuzz and gcc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7919