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.

No, unfortunately it won't. :( The problem started with the update to HarfBuzz 
2.7.2,  and there the opt level was HIGH. I also tested manually compiling with 
-O1 (which we don't really have a level for in the build system) and even that 
was too problematic for gcc.

But another approach is possible. I talked off-list with Erik, and he had 
noticed (as had I) that a single file in harfbuzz was responsible for the 
lion's share of the build time regression. What he did, though, that I didn't 
come to think of, was to try to change optimization level for just that file. 
This fixes most of the build time regression, while being a much less intrusive 
fix. It also makes sense to do this fix for clang, since the 8 second 
regression seen there is basically also completely due to this file.

So I'll upload an update too this fix that is more conservative, and only 
changes opt level for a single file.

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

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

Reply via email to