RFR: 8283323: libharfbuzz optimization level results in extreme build times

[Magnus Ihse Bursie]

On Wed, 23 Mar 2022 19:35:22 GMT, Phil Race <prr 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.
>
> We definitely do not want to downgrade the optimisation level of the entire library.
> Performance of this library actually matters quite a lot.
> When we added some additional checking to the previous library we used (ICU) we had complaints of as much as 20% loss
> in PDF conversion (a backend process) and we've had escalations on user responsiveness in editors due to the computational complexity of layout vs just counting glyph advances.
> Getting that performance back was a lot of work .. except increasing compiler optimisation was the easy one that made a big difference. 
> To see the performance degradation may require a specific combination of font (Linux fonts vary widely) and the text being laid out. 
> The example we used in the previous case required a windows font, so I don't have a handy test case  I know will show this .. and it was years ago .. 
> 
> Looking at the list of files from Erik, I think we don't use the subset functionality. Certainly not directly and likely not at all.
> So downgrading that probably won't have any impact at all at runtime.
> 
> But hb-ot-layout.cc is one of the most important files in the library, maybe the most important.
> 
> I strongly suggest that one not be downgraded just for 7 seconds of build time.

@prrace If we're not using the subset functionality, can we remove the files entirely, or exclude them from compilation?

(In the meantime, I'm preparing a patch which only limits optimization to the two subset files Erik listed)

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

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