gsmiller commented on code in PR #13463:
URL: https://github.com/apache/lucene/pull/13463#discussion_r1635558572
##########
lucene/core/src/java/org/apache/lucene/util/hnsw/BlockingFloatHeap.java:
##########
@@ -72,12 +72,13 @@ public float offer(float value) {
* <p>Values must be sorted in ascending order.
*
* @param values a set of values to insert, must be sorted in ascending order
+ * @param len number of values from the {@code values} array to insert
* @return the new 'top' element in the queue.
*/
- public float offer(float[] values) {
+ public float offer(float[] values, int len) {
lock.lock();
try {
- for (int i = values.length - 1; i >= 0; i--) {
+ for (int i = len - 1; i >= 0; i--) {
Review Comment:
Yeah, I considered that as well and I don't really have a strong opinion
either way. Offering everything without short-circuiting is probably a slightly
cleaner/simpler solution so maybe that's a better way to go unless performance
testing for some reason shows otherwise (but I find it had to imagine we'd see
a big difference). That solution removes the need for the scratch array, which
is nice.
--
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
