lucene
lucene copied to clipboard
NeighborArray is now fixed size
Remove the ability for NeighborArray
to grow. Always allocates it one larger than requested, to reserve space for a temporary neighbor.
Fixes https://github.com/apache/lucene/issues/11783
@msokolov Thanks for tackling this. I was also thinking to remove NeighborArray
of resizing, which makes logic simplier.
I was thinking a better approach would be to leave it to uses of NeighborArray
to define maxSize
, and not add +1 in the NeighborArray
class itself as this PR suggests. For example, OnHeapHnswGraph already adds +1 when creating NeighborArray
, as well as HnswGraphBuilder.
What do you think?
I was thinking a better approach would be to leave it to uses of NeighborArray to define maxSize, and not add +1 in the NeighborArray class itself as this PR suggests
I guess I was thinking that since this class only has a single use, it wouldn't matter? But it definitely is better encapsulation to move the sizing logic to the place where we know how many we need. +1 to have consumers do it, especially since at least in one place they already do :) I'll follow up with a patch
Also -- now that I see this I realize that most likely we are never exercising this resize capability, so removing it won't really help performance / memory usage as I was hoping. But it still seems like a good cleanup?
Wow, lots of fun discussion here, including specifics of how Java conditionals are evaluated. @msokolov is this still relevant? The HNSW code has been red-hot lately; maybe this change was already effectively done?
Thanks @msokolov. This looks like a nice tool, helpful for giving demos of cool Lucene features at conferences, but it looks like consensus is we should not add it to Lucene? Maybe luceneutil instead?
Edit: sorry, wrong PR, heh. NotEnoughCaffeineException
!
This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the [email protected] list. Thank you for your contribution!