On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie <i...@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. ------------- PR: https://git.openjdk.java.net/jdk/pull/7919
