Skip to content

Conversation

@nevans
Copy link
Collaborator

@nevans nevans commented Dec 8, 2025

The results are highly dependant on data, YJIT, etc... but in my tests this implementation seems to consistently run faster.

Comparison:
             builtin: L ^ R
                  local:       967.0 i/s
before #567 (559b86a8b):       917.5 i/s - 1.05x  slower
before #562 (a228ee1d5):       901.2 i/s - 1.07x  slower
                v0.5.12:       840.0 i/s - 1.15x  slower
                 v0.5.0:       830.7 i/s - 1.16x  slower
                v0.4.21:       797.0 i/s - 1.21x  slower
                 v0.5.9:       790.4 i/s - 1.22x  slower

             builtin: L.xor! R
                  local:       960.9 i/s
before #567 (559b86a8b):       954.3 i/s - 1.01x  slower
before #562 (a228ee1d5):       940.0 i/s - 1.02x  slower
                v0.5.12:       796.4 i/s - 1.21x  slower
                 v0.5.0:       633.9 i/s - 1.52x  slower
                v0.4.21:       620.1 i/s - 1.55x  slower
                 v0.5.9:       619.0 i/s - 1.55x  slower

When I first wrote this code, the master branch was consistently 1.3x-1.5x slower. The speedup is much less now, so other implementation details are probably more important. Specifically, most of the speedup probably came from the change in #550, which coerced rhs to a SequenceSet before using it.

When the internal set data implementation is changed (see #484), this and other operations should be re-evaluated. I suspect an iterative "merge" may be the fastest overall approach, but that code is more complex than simply relying on the core add/subtract/complement methods with simple boolean algebra.

@nevans nevans added the performance related to CPU use, memory use, latency, etc label Dec 8, 2025
The results are highly dependant on data, YJIT, etc... but in my tests
this implementation seems to _consistently_ run faster.

```
Comparison:
             builtin: L ^ R
                  local:       967.0 i/s
before #567 (559b86a):       917.5 i/s - 1.05x  slower
before #562 (a228ee1):       901.2 i/s - 1.07x  slower
                v0.5.12:       840.0 i/s - 1.15x  slower
                 v0.5.0:       830.7 i/s - 1.16x  slower
                v0.4.21:       797.0 i/s - 1.21x  slower
                 v0.5.9:       790.4 i/s - 1.22x  slower

             builtin: L.xor! R
                  local:       960.9 i/s
before #562 (a228ee1):       954.3 i/s - 1.01x  slower
before #567 (559b86a):       940.0 i/s - 1.02x  slower
                v0.5.12:       796.4 i/s - 1.21x  slower
                 v0.5.0:       633.9 i/s - 1.52x  slower
                v0.4.21:       620.1 i/s - 1.55x  slower
                 v0.5.9:       619.0 i/s - 1.55x  slower
```

When I first wrote this code, the `master` branch was consistently
1.3x-1.5x slower.  The speedup is much less now, so other implementation
details are probably more important.  When the internal set data
implementation is changed (see #484), this and other operations should
be re-evaluated.  I suspect an iterative "merge" may be the fastest
overall approach, but that code is more complex than simply relying on
the core add/subtract/complement methods with simple boolean algebra.
@nevans nevans force-pushed the sequence_set/faster-xor branch from 131997d to a42108a Compare December 8, 2025 14:27
@nevans nevans changed the title ⚡️ Make SequenceSet#xor ~1.4x faster ⚡️ Slightly faster SequenceSet#xor Dec 8, 2025
@nevans nevans merged commit 1ea68b2 into master Dec 8, 2025
32 checks passed
@nevans nevans deleted the sequence_set/faster-xor branch December 8, 2025 14:30
@nevans nevans added the sequence-set Any code the IMAP `sequence-set` data type or grammar rule, especially the SequenceSet class. label Dec 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance related to CPU use, memory use, latency, etc sequence-set Any code the IMAP `sequence-set` data type or grammar rule, especially the SequenceSet class.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants