On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken <mbaes...@openjdk.org> wrote:
> In the makefile we reset LIBFONTMANAGER optimization, but is always set to > HIGHEST so we can avoid the resetting. The problem with changing optimization levels is that folks are generally conservative and worried that things might break, that are hard to detect. I'm not convinced that the risk of changing optimization level is any larger than upgrading the compiler though, so maybe that is not a very good argument. As has been pointed out e.g. by Phil, not all libraries are performance critical. With that said, maybe such libraries should be optimized for size instead? (In many cases that also brings along a speed performance, even if it by no means guaranteed.) Changing optimization levels should not only be measured on the execution speed of the final product, but also on how much it affects the build time. If you feel up for it, I suggest that you go through all libraries you want to update, change the optimization levels to what you think is reasonable, measure any relevant performance benchmarks before and after, and also the the build time. (hint: Use e.g. `make java.desktop-libs-only JOBS=1 LOG=info` to get a build speed number that you can compare across compiler flag changes) Run all relevant tests that stress that native component. Then you can post a PR and suggest that we change the optimization level. I'm all in favor of this, I'm not just in favor of having to do all the work needed myself. :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2623151495
