Optimize ixor  #338

Activity

1. srinathshrestha commented on Sep 26, 2026

   

   srinathshrestha

   on Sep 26, 2026

   More actions

   I checked the current Go implementation against the Java optimization linked here. ixorBitmap still computes the XOR cardinality first and then performs the XOR in a second pass for dense results. On an M4 pro, a prototype that XORs into the receiver first, computes its cardinality, and converts only when sparse improved a 50%-dense case from approximately 742 ns/op to 677 ns/op, with zero allocations in both versions. I’d add benchmarks across dense, sparse, and near-empty results, along with focused in-place correctness tests. Is this issue still available for a PR?