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

[Magnus Ihse Bursie]

On Wed, 23 Mar 2022 21:13:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference linux machine. This was one of the four culprits that caused a 25-30% build time regression over the last two years.
>> 
>> The problem here was that the new HarfBuzz code caught really bad behaviour from gcc when compiling with optimizations. The official HarfBuzz build does not use any -O flags at all for gcc, so presumably the HarfBuzz team is:
>> 
>> a) not thinking compiler optimization is important for the performance of this library, and
>> b) unaware that their code causes such a headache for gcc.
>> 
>> (Other compilers fare much better: visual studio makes no difference at all, and for clang just a small regression was observed.)
>> 
>> The current optimization level was introduced by [JDK-8255790](https://bugs.openjdk.java.net/browse/JDK-8255790), which were really about moving libharfbuzz compilation back into libfontmanager. I could find no comments/discussion relating to the change of optimization level, so I assume it was incidental, and just seemed good at the time.
>> 
>> This patch changes the optimization level to `SIZE` (which is the closest thing we have to no optimization level) on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore HIGHEST for entire lib, just set SIZE to two files

Changing just these two files removes most of the build time regression. I'm okay with that.

Going forward I'd like to understand *why* this is on the critical path, and if there's anything we can do about it. But that's much more complex than just addressing this regression in build times. I'm also pondering if we could help make somehow by hinting that files like subset and layout take a long time to compile, and schedule them early, so we don't suddenly find us inn the position of waiting for just them to be able to link the library. I'm suspecting that if the file was named hb-aarrdwark.cc it would not have impacted the total build time as much as now...

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

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