perf: optimize parseInt with 4-digits-at-a-time parsing#895
Closed
He-Pin wants to merge 6 commits into
Closed
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.
Add @inline annotation to flushBuffer, flushCharBuilder, visitNonNullString, and appendString methods. These are called frequently during materialization and benefit from inlining to reduce function call overhead on Scala Native. Benchmark results (manifestJsonEx): - Before: jrsonnet 2.11x faster - After: jrsonnet 1.62x faster (23% gap reduction)
This reverts commit 3a966e1.
Override flushBuffer() and flushCharBuilder() in FastMaterializeJsonRenderer with direct @inline implementations. Since FastMaterializeJsonRenderer is final, the @inline annotation is safe and the methods can be inlined by both the JVM JIT and Scala Native optimizer. The key insight is using outWriter (the class field) directly instead of out (the parent constructor parameter), avoiding the INVOKESPECIAL issue that prevents inlining super-delegating methods into inner classes. Benchmark results (manifestJsonEx): - Before: jrsonnet 2.11x faster - After: jrsonnet 1.50x faster (29% gap reduction)
Inspired by jsoniter-scala's SWAR digit parsing technique, process 4 decimal digits at a time instead of 1. This reduces the number of loop iterations and charAt calls by 4x for the common case. The optimization validates all 4 digits before combining them, falling through to the scalar loop if any non-digit is found. Uses Double accumulator throughout to handle numbers beyond Long range. Benchmark results (parseInt): - Before: jrsonnet 1.97x faster - After: jrsonnet 1.27x faster (36% gap reduction) Reference: plokhotnyuk/jsoniter-scala@df92601
Contributor
Author
|
Closing in favor of a clean PR with only the parseInt optimization. |
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.parseIntfunction was 1.97x slower than jrsonnet (Rust implementation) on Scala Native. The main bottleneck was the per-character digit parsing loop.Key Design Decision
Inspired by jsoniter-scala's SWAR digit parsing technique, process 4 decimal digits at a time instead of 1. This reduces the number of loop iterations and
charAtcalls by 4x for the common case.Modification
Changed
sjsonnet/src/sjsonnet/stdlib/StringModule.scala:Doubleaccumulator throughout to handle numbers beyond Long rangeBenchmark Results
Scala Native vs jrsonnet (hyperfine)
JMH (JVM)
Baseline JMH benchmarks are stable; the change benefits all platforms.
Analysis
The 4-digits-at-a-time approach reduces loop overhead by processing 4 digits per iteration instead of 1. For the benchmark input "-123949595" (9 digits), this means 2 iterations instead of 9.
The optimization validates all 4 digits before combining them, falling through to the scalar loop if any non-digit is found. This ensures correct error reporting for invalid inputs.
References
Result
./mill __.test)./mill __.reformat)