paulirwin commented on issue #1151: URL: https://github.com/apache/lucenenet/issues/1151#issuecomment-2751354504
@NightOwl888 I think that approach makes sense. It was an alternative I mentioned (although thought through far less than you have here) on my prototype PR #1152. In that PR I confirmed that if the mmap is buffered, the performance problems go away, and it performs better than the other two directory implementations, like Java. Performance is actually slightly better than Java (as we would hope, but still great to see!) except for in the NIOFS case, which is slower in Lucene.NET for different reasons. My PR still has a good amount of failing unit tests that would need to be addressed if we want to take that approach though. Regardless, we've demonstrated that buffering is the solution, because reading a single byte from a mmap in .NET is painfully slow. (Aside: my performance measuring was on macOS, which gets NIOFSDirectory from `FSDirectory.Open`, probably for historical reasons. I think it's clear at this point that once we fix this issue, we should return MMapDirectory on macOS as well.) I'm good with your plan above, although I am less familiar with the J2N code than you are. If you wouldn't mind taking a first pass at that on the J2N side, we can then compare approaches and see how they fare in performance testing. IMO, if BufferedIndexInput comes out ahead, we should still consider that, although there might likely be concurrency/scale issues (including concurrent writes) with that approach I haven't considered yet that would need to be considered as well. Regardless, it sounds like for methods like ReadInt32, we should do the J2N change anyways. -- 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: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
