uschindler edited a comment on pull request #2176: URL: https://github.com/apache/lucene-solr/pull/2176#issuecomment-754299385
Hi @msokolov, thanks for the speed test - I wanted to wait for the specialists to do it. As said before, we should report slowness (or improvements) to the Hotpsot/OpenJDK people. I was expecting a result like this due to the early stage of the development and misisng Hotspot optimizations. Just to clarify: In your code, you are reading the floats with a series of readInt() from the indexinput, converting them to float? If that's the case, I would say: this is expected! From what I figured out on the mailing lists: loops using `long` as an index vs. `int` as an index are not supported well by Hotspot yet. The position() argument of good old ByteBuffers is a 32bits `int` and whenever you read from memory it uses this int (`index += 4`). Those loops are easy optimized. With `MemorySegment`s, the pointer is a 64bit `long` named `curPosition` in our `MemorySegmentIndexInput`. Hotspot has no idea how to optimize that loop of readInt() statements! I am not sure if this is fully true at this stage but that's my first guess, I will discuss this with Maurizio. Interestingly, I would have expected that `readBytes()` and `readLELongs()` are slower due to the overheads by wrapping all those `slice()` calls and `MemorySegment.ofArray()`all producing short living object instances! But I seem to be proved wrong :-) ---------------------------------------------------------------- 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. 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
