sohami commented on PR #12374: URL: https://github.com/apache/lucene/pull/12374#issuecomment-1597927888
> +1 to not having two ways to customize slicing. >> the approach to override a method to compute slices given a list of segments looks more user-friendly to me than having to compute slices up-front? Agreed to this however the `slices` method doesn't provide got way to overwrite the computation for all the cases as it is called from base class constructor. > For reference, this [20-years-old comment](https://github.com/apache/lucene/commit/360d91dde75244b3b73793ac3a2e6c8737c45f9f) on IndexSearcher about making sure to reuse IndexSearcher instances is outdated, all IndexSearcher constructors are cheap compared to the work that running any query would need to do. It's actually required to create a new IndexSearcher for every search if you wish to leverage IndexSearcher's timeout support. Thanks for sharing the context > If there is reluctance to computing slices on every call to #search, could we compute slices lazily and cache them in getSlices()? This way, it wouldn't be needed to increase the visibility of slices to protected? With `getSlices()` based approach and using member variable `leafSlices` to cache the computed value, my only concern is that it will be hard to enforce any usage to fetch the slices within `IndexSearcher` to use `getSlices` always (and not the cached member directly). With that in mind I guess its cleaner to compute `slices` always and remove the member `leafSlices`. Thoughts ? -- 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
