uschindler commented on PR #13337: URL: https://github.com/apache/lucene/pull/13337#issuecomment-2098635698
> Some questions about the API, curious to get your thoughts: > > * Should we remove `ReadAdvice#WILL_NEED` and instead introduce a new API such as `NativeAccess#madviseWillNeed`. It's a bit awkward right now that we have a `ReadAdvice` constant that is rejected in the only place where we allow `ReadAdvice` objects: `IOContext`. What do you think @uschindler ? I had the same problem. I don't like the changes in IOContext (i reverted some of them and used a method to disallow specific ReadAdvice). Indeed a new method that is for the WillNeed case only is a good idea. Actually the willneed is different to the readahead settings. So possibly we can separate them in nativeaccess. > * Should we rename `prefetch()` to `willNeed()` to better draw the parallel with `madvise`/`fadvise`? I have no preference. > * I'm contemplating changing the signature from `void prefetch()` to `void prefetch(long offset, long length)`. The benefit is that this would allow reading from multiple places with a single `IndexInput`. E.g. one could parallelize the I/O of reading N stored documents on a single `StoredFieldsReader` instance instead of creating one reader (with its own `IndexInput` clone) per document. I'll do this change if there are no objections. This was my first idea when looking at the first method. With current code it is completely undefined how much the prefetch should read. Making it absolute is not bad, but should be limited to the RandomAccessIndexInput interface. So basically we can have both variants. The sequential one should be part of IndexInput and is a must to be implemented. The other should not be in IndexInput only in the random slice. Basically the current code doe snot preload accrodd boundaries, but implemebting that is easy and can be one in MemorySegmentIndexInput in the same way like reading arrays, also cross boundary. It would just be 2 calls. -- 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
