uschindler commented on pull request #592: URL: https://github.com/apache/lucene/pull/592#issuecomment-1010776138
Hi @gf2121, thanksfor taking the time to test more. It looks really like the guar checks are not affecting the whole thing, but as always we don't really know where the optimization effects are coming from. For such low level changes it often also varies between different JVM version (there are differences between JDK 11 and JDK 17). Actually the code SHOULD not make any difference, but it has. I see that you carefully also save the position before the try block and restore it on boundary crossing exception. What I don't like: ByteBufferGuard is just a hack and should not contain any program code except guarding. So I am not happy of including readVInt code there. Have you tried in just moving the `Guard#readVInt()` code into `ByteBufferIndexInput#readVInt()` inside its `try` block calling `guard.readByte()` -- all guard methods should be inlined by JVM very early? This is where it belongs! Nevertheless I wonder why Hotspot is not able to apply the optimization. The only thing we spare is the try/catch, but maybe thats the issue here that prevents it from being inlined into readVInt. If that helps we can also try the same on the MemorySegment one from #518. -- 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
