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

[Erik Joelsson]

On Wed, 23 Mar 2022 12:25:08 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.

> I have a question, though, because I suppose font rendering engine is performance sensitive. AFAICS, the `LIBFONTMANAGER_OPTIMIZATION` was changed from `HIGH` to `HIGHEST` here: [05fe06a6#diff-c75e2d581b3730cf900075cedb66ac72eaba40fbbd92eaac5710161830b572b4L534-R491](https://github.com/openjdk/jdk/commit/05fe06a6#diff-c75e2d581b3730cf900075cedb66ac72eaba40fbbd92eaac5710161830b572b4L534-R491)
> 
> Does it mean we should instead downgrade to `HIGH`, not `SIZE`? Would that recover the build times?

For GCC on Linux, that doesn't make a difference as both HIGH and HIGHEST translate to -O3.

I've been looking a bit at this too, and there are a handful of files that stick out, hb-subset.cc is the worst one. Here are the top three on my Linux host (using 31 threads), first with -O3 and then with Os:

[TIME:0:18.36] hb-subset-plan.cc
[TIME:0:21.53] hb-ot-layout.cc
[TIME:0:35.63] hb-subset.cc

[TIME:0:12.51] hb-subset-plan.cc
[TIME:0:14.81] hb-ot-layout.cc
[TIME:0:21.40] hb-subset.cc

On my mac (6 threads, but single core perf is higher), the corresponding numbers are:

[TIME:0:14.46] hb-subset-plan.cc
[TIME:0:19.64] hb-ot-layout.cc
[TIME:0:27.45] hb-subset.cc

[TIME:0:11.69] hb-subset-plan.cc
[TIME:0:16.00] hb-ot-layout.cc
[TIME:0:20.68] hb-subset.cc

This is certainly not quite as bad, but still a clear difference.

The reason this has such a high impact on total compilation time is due to how java.desktop ends up being one of the last top level targets on the critical path of possible concurrency. So a single compilation unit here will stall the whole process on a machine with many threads (32 in my case). On a smaller machine, this impact will be much less pronounced. Here are the total compilation times for "make exploded-image" with a few different settings:

all libfontmanager HIGHEST
linux: 4m14.174s
macosx: 7m8.736s

all libfontmanager SIZE
linux: 3m56.134s
macosx: 7m5.966s

just the above 3 files SIZE
linux: 3m57.009s
macosx: (skipped, no point)

The difference on the smaller macosx machine is negligible. Most of the compilation time gain on the big machine is gained by just dropping the optimization level on a few files. 

One could certainly argue that dropping the optimization level for libfontmanager is only helping a rather niche usecase. There could certainly be other compilation units that would have a similar effect on total build time due to how they end up on the critical path, I would be surprised if there aren't. The question is which ones we can safely drop the optimization level for without adversely affect performance of the finished product.

For this particular change it's probably better to at least just drop it for one or a few files.

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

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