[ 
https://issues.apache.org/jira/browse/LUCENE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17423052#comment-17423052
 ] 

Robert Muir commented on LUCENE-10130:
--------------------------------------

btw, being unsure about the data patterns was part of the reason of adding the 
getAndSet to the BitSet interface in the patch. It makes the testing approach 
easier, but also makes it possible for calling code to use or switch different 
BitSet implementations (e.g. approaches such as BitSet.of). 

In general it seems a bit strange to have getAndSet on the FixedBitSet (where 
it may save little) but not have it on the SparseFixedBitSet (where it may save 
a bit more due to the added two-stage tables/access costs).


> 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
>
>
> 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

Reply via email to