original-brownbear commented on PR #13936: URL: https://github.com/apache/lucene/pull/13936#issuecomment-2425018683
I think the queue methods changed here in isolation get a far bigger improvement than 1% in many cases. Plus making methods like the ones adjusted here smaller and easier on the CPU cache tends to help the performance of "neighboring" code as well in many case (hence the across the board speedup in the luceneutil run). I don't think this is the result of a JVM bug, it's just something that is hard to optimize by the compiler with Java so dynamic. It's a combination of two things. 1. Current JIT implementations don't really take advantage of `final` fields in normal objects https://openjdk.org/jeps/8132243, https://bugs.openjdk.org/browse/JDK-8058164 and so on. That's what makes caching stuff like size or the heap array so helpful. 2. Field loads simple result in larger methods when measuring byte code size than caching in a local variable. Unless JIT implementations become more sophisticated (looking at e.g. https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109461.html it doesn't look like that's happening anytime soon), avoiding field access tends to result in deeper inlining here and there. -- 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: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
