[ 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