lweitzendorf opened a new pull request, #3203: URL: https://github.com/apache/jackrabbit-oak/pull/3203
https://issues.apache.org/jira/browse/OAK-12448 ## Summary Inline segment strings are now decoded with `new String(byte[], UTF_8)` instead of `buffer.decode(UTF_8).toString()`. The old path allocated an intermediate UTF-16-sized `CharBuffer`, ran the general `CharsetDecoder`, and copied the result again in `toString()`. Building the string directly from bytes lets the JDK use its optimized decoding paths, including the ASCII fast path and compact strings. - Inline decoding is extracted into `SegmentData.decodeString(int recordReferenceOffset, int length)`. - Large, externally stored strings are handled exactly as before. - No new `oak-commons` API is added. ## Tests `RecordTest#testStringRoundTrip` writes and reads back strings covering: - empty, ASCII, multibyte (2- and 3-byte) and supplementary (4-byte) characters - lengths around the small, medium and large storage boundaries (127/128/129, 16510–16513, 40000) ## Benchmark (JMH 1.37, JDK 23) This is a microbenchmark of the decoding strategy alone (`UTF_8.decode(ByteBuffer).toString()` vs `new String(byte[], UTF_8)`), measured with `-prof gc`: | input | old ns/op | new ns/op | speedup | old B/op | new B/op | |---|---|---|---|---|---| | ASCII 8 | 19.3 | 4.9 | 3.9× | 192 | 48 | | ASCII 40 | 23.1 | 6.9 | 3.3× | 288 | 80 | | ASCII 200 | 35.3 | 11.4 | 3.1× | 768 | 240 | | ASCII 4000 | 471 | 146 | 3.2× | 12168 | 4040 | | multibyte 200 | 158 | 125 | 1.3× | 824 | 832 | | multibyte 4000 | 2995 | 2400 | 1.25× | 12984 | 15272 | ASCII is the common case for JCR names and paths. There it is about 3–4× faster and allocates about 3–4× less. Heavily multibyte input is close to neutral: slightly faster, with somewhat more allocation at large sizes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
