perf: inline FastMaterializeJsonRenderer hot methods#896
Closed
He-Pin wants to merge 5 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)
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.manifestJsonExfunction was 2.11x slower than jrsonnet (Rust implementation) on Scala Native. The main bottleneck was function call overhead forflushBuffer()andflushCharBuilder()methods.Key Design Decision
Override
flushBuffer()andflushCharBuilder()inFastMaterializeJsonRendererwith direct@inlineimplementations. SinceFastMaterializeJsonRendereris afinalclass, the@inlineannotation 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 ofsuper.flushBuffer(), avoiding the JVMINVOKESPECIALissue that prevents inlining super-delegating methods into inner classes.Modification
Changed
sjsonnet/src/sjsonnet/Renderer.scala:flushBuffer()with direct@inlineimplementationflushCharBuilder()with direct@inlineimplementationoutWriterfield directly instead ofsuperdelegationBenchmark Results
Scala Native vs jrsonnet (hyperfine)
JMH (JVM)
Baseline JMH benchmarks are stable; the change benefits all platforms.
Analysis
The
@inlineannotation onfinalclass methods allows the Scala Native optimizer to inline these hot-path methods at link time. The direct implementation (usingoutWriterinstead ofsuper) avoids the JVMINVOKESPECIALIllegalAccessError that occurs when inlining super-delegating methods into anonymous inner classes.References
@inlinedocumentationINVOKESPECIALspecificationResult
./mill __.test)./mill __.reformat)