[
https://issues.apache.org/jira/browse/LUCENE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17423508#comment-17423508
]
Robert Muir commented on LUCENE-10130:
--------------------------------------
I attached a followup patch to try to give some more love to the "set" codepath.
These helper methods (e.g. insertBlock/long) don't need to recompute shifts
that their callers already did. Not sure the compiler can eliminate this
automatically since i'm not sure stuff is getting inlined.
Also insertLong gets hit hard by vectors indexing, but it seems to spend more
cycles trying to incrementally update ramBytesUsed than actually setting bits.
We can be a little less extreme about this: insertBlock already bakes in
"worst-case" alignment (long[1]), so lets just adjust with a simpler
calculation.
> HnswGraph could make use of a SparseFixedBitSet.getAndSet
> ---------------------------------------------------------
>
> Key: LUCENE-10130
> URL: https://issues.apache.org/jira/browse/LUCENE-10130
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Robert Muir
> Priority: Major
> Attachments: LUCENE-10130.patch, LUCENE-10130_round2.patch
>
>
> Currently HnswGraph uses SparseFixedBitSet "visited" to track where it has
> already been. The logic currently looks like this:
> {code}
> if (visited.get(entryPoint) == false) {
> visited.set(entryPoint);
> ... logic ...
> }
> {code}
> If SparseFixedBitSet had a {{getAndSet}} (like FixedBitSet), the code could
> be:
> {code}
> if (visited.getAndSet(entrypoint) == false) {
> ... logic ...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
