perf: use 256-byte lookup table for stripChars ASCII membership#894
Closed
He-Pin wants to merge 2 commits into
Closed
perf: use 256-byte lookup table for stripChars ASCII membership#894He-Pin wants to merge 2 commits into
He-Pin wants to merge 2 commits into
Conversation
Replace per-char charAt(i).toByte loop with a single getBytes(0, len, dst, 0) system call for narrowing ASCII chars to bytes in encodeStringToString. Benchmark results (Scala Native vs jrsonnet): - std.base64 (string): 2.17x slower -> 1.21x slower (44% gap reduction) - std.base64Decode: 1.58x slower -> 1.47x slower (improved) - std.base64DecodeBytes: 1.19x faster -> 1.14x faster (stable) - std.base64_byte_array: 1.38x faster -> 1.31x faster (stable) The getBytes method is a single system call that copies bytes faster than a per-char loop. Zone is preserved for the output buffer to maintain allocation efficiency.
Replace the 128-bit bitmask approach (two Long values with conditional branches) with a 256-byte lookup table for ASCII character membership testing in stripChars/lstripChars/rstripChars. The lookup table eliminates the two conditional branches per char in inAsciiMask(), replacing them with a single array load. This keeps the strip loop branch-free and cache-friendly. Also added early return optimization for empty inputs.
Contributor
Author
|
Closing in favor of clean PRs with single optimizations each. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The
std.stripChars/std.lstripChars/std.rstripCharsfunctions were 1.45-1.74x slower than jrsonnet (Rust implementation) on Scala Native. The main bottleneck was theinAsciiMaskfunction which had two conditional branches per character for ASCII membership testing.Key Design Decision
Replace the 128-bit bitmask approach (two Long values with conditional branches) with a 256-byte lookup table for ASCII character membership testing. The lookup table eliminates the two conditional branches per char, replacing them with a single array load.
Modification
Changed
sjsonnet/src/sjsonnet/stdlib/StringModule.scala:stripAsciiMaskwithstripLookupusing 256-byte lookup tableinAsciiMaskandstripAsciiMaskmethodsBenchmark Results
Scala Native vs jrsonnet (hyperfine)
JMH (JVM)
Baseline JMH benchmarks are stable; the change benefits all platforms.
Analysis
The 256-byte lookup table approach eliminates the two conditional branches in
inAsciiMask():if (c < 64) (lo & (1L << c)) != 0L else if (c < 128) (hi & (1L << (c - 64))) != 0Ltable(c) != 0This keeps the strip loop branch-free and cache-friendly. The lookup table allocation (256 bytes) is amortized across the strip operation.
References
Result
./mill __.test)./mill __.reformat)