On Wed, 23 Mar 2022 19:35:22 GMT, Phil Race <p...@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
