On Wed, 23 Mar 2022 23:38:52 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update comment to show we don't care about these files. > > Do we really want to change the product performance characteristics based on > the compilation time? Can we try parallelize/cache or something first? > @mrserb Phil said that we don't even use the subset part of harfbuzz. > > And unless you're backing up your claim that this patch is changing runtime > characteristic with data, that's just a guess, just like the initial > optimization level of this library (and as most of the native libraries in > the JDK... :-() was just a guess. Otoh, that we get a build time regression > for these two files is a proven fact. > > What is it you want to cache? It is a reasonable question. Build times might seem important to a small number of developers but runtime performance is King. That's why I asked to reduce it to just the files we don't care about. Would we give up even 0.1% of hotspot GC performance on Linux to avoid 30 seconds of compile time ? I doubt it. And haven't we improved compile time a lot with the parallelism ? So are we now over-optimising in the wrong place ? I mean good to keep an eye on it but I mean if a previous build arch took 15 mins and now with parallelism we take 3 mins and 45 secs .. is it so bad to be back up to 4 mins for more runtime benefit ? (Numbers entirely made up) There's always going to be a long pole (something that is last) and the questions are whether its understood and for a good reason and so forth. I mean we can doubtless try to improve but at some point it is diminishing returns. Perhaps someone can ask gcc devs why they are so slow on this code ? Maybe there's a good reason that helps runtime or maybe they just have design issues. They may want to know. ------------- PR: https://git.openjdk.java.net/jdk/pull/7919
