jrudolph commented on PR #418: URL: https://github.com/apache/incubator-pekko-http/pull/418#issuecomment-1893506385
> the inliner has been used in the most critical parts of Scala ecosystem including scalac itself for many years now scalac is a different case as scalac is an application with only few dependencies and not a library, so it can benefit in different ways from inlining than a library. > even parboiled2 is using the inliner This is somewhat irrelevant since much of the performance critical parts of parboiled2 are only generated in the user code at a different compilation time with different settings, and as you know no performance benchmarks have been run before merging that change, especially not in the downstream libraries... In general, for best performance you will have to evolve and continuously benchmark your codebase including all your settings and the environment. This is hard, especially since we do not have any control over e.g. the choice of JDK which can have a huge impact. Incidentally, in my tests, JDK 8 is often still the fastest option in many cases. The [inliner documentation](https://docs.scala-lang.org/overviews/compiler-options/optimizer.html#inliner-heuristics-and-inline) shows this warning right at the front: > Don’t enable the optimizer during development: it breaks incremental compilation, and it makes the compiler slower. Only enable it for testing, on CI, and to build releases. How do we deal with it? How is developer efficiency impacted by this change? > But ultimately even minor performance gains is still performance. That's my point, right now, in my tests, there's zero performance difference (but I cannot test it comprehensively) but we added complexity and don't fully understand the consequences. The only thing I ask for is that we don't just do changes because we think they might be useful but that we collect evidence first and carefully evaluate pros and cons, especially if the evidence is so scarce. Right now the balance is: - added complexity - potential productivity and correctness issues during development - untested performance impact in comprehensive tests +/- little/zero negative/positive performance change in random testing on my machine -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For additional commands, e-mail: notifications-h...@pekko.apache.org
