original-brownbear commented on code in PR #13472: URL: https://github.com/apache/lucene/pull/13472#discussion_r1664618492
########## lucene/CHANGES.txt: ########## @@ -277,6 +277,15 @@ Optimizations * GITHUB#12941: Don't preserve auxiliary buffer contents in LSBRadixSorter if it grows. (Stefan Vodita) +Changes in runtime behavior +--------------------- + +* GITHUB#13472: IndexSearcher now executes tasks on the thread that invoked a search as well as its configured + executor. Users that invoke searches from threads not belonging to the executor configured in IndexSearcher should + reduce the executor's thread-count by 1 to retain the previous level of parallelism. Searches invoked from a thread + not part of the IndexSearcher's executor will now complete on the calling thread in case the executor is busy or + blocked and unable to complete any work. Review Comment: My idea was that benchmarking here showed how very sensitive numbers are to thread count in many cases (and more threads is definitely not a win in all cases). Seemed reasonable to give people a hint to work with if they see a regression? (because they went from CPU count threads to more than CPU count and have enough memory so the whole thing gets nothing from overcommit for example) -- 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
