[GitHub] [solr] magibney edited a comment on pull request #2: SOLR-14185: introduce DocSet.iterator(LeafReaderContext), replacing Filter where possible

[GitBox <gi...@apache.org>]

magibney edited a comment on pull request #2:
URL: https://github.com/apache/solr/pull/2#issuecomment-802891894


   > Do you have something on-hand to perf-test this?
   
   I don't really have anything on-hand, unfortunately. Some indecision here too (hence my delayed response), due to the fact that I'm having a hard time brainstorming anything that I'd expect to make a difference (this being close to a refactoring in essence); but what you've suggested would serve well as a sanity check. How large would you consider a "large index" to be, for this purpose?
   
   Worst-case would probably involve combinations of `fq`, to generate uncached intersections. Because the "work" of determining leaf boundaries on SortedIntDocSet is now cached in the DocSet itself, as opposed to in the Filter, I'd expect performance of iterators over _cached_ DocSets to be better (assuming any perceptible difference at all). Are there any cases where iterators would be requested e.g. for the first leaf, but not later leaves (e.g. some kind of shortcircuit -- maybe `facet.exists`?)? That could also be a difference, since the boundaries for all leaves are now calculated up-front when the first iterator is requested.
   
   tbh I'd be surprised if any of this made a difference (improvement or regression) ... but of course nobody ever _expects_ to be surprised :-)


-- 
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:
users@infra.apache.org