On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> This PR seeks to improve formatting of hex digits using `java.util.HexFormat` > somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result > of `HexFormat.of().withUpperCase()`, and removing tiny allocation that > happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on > throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit > Diff% > HexFormatBench.appenderLower 15 1,330 ± 0,021 1,065 ± 0,067 us/op > 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ± 0,185 0,007 ± 0,000 MB/sec > -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ± 0,000 0,007 ± 0,000 B/op > -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ± 0,013 1,065 ± 0,054 us/op > 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ± 0,111 0,007 ± 0,000 MB/sec > -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ± 0,000 0,007 ± 0,000 B/op > -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ± 0,022 1,065 ± 0,036 us/op > 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ± 0,559 0,007 ± 0,000 MB/sec > -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ± 0,000 0,007 ± 0,000 B/op > -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ± 0,009 1,033 ± 0,014 us/op > 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ± 0,074 0,007 ± 0,000 MB/sec > -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ± 0,000 0,007 ± 0,000 B/op > -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ± 0,001 0,119 ± 0,008 us/op > 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ± 0,000 0,007 ± 0,000 MB/sec > -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ± 0,000 0,001 ± 0,000 B/op > -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... I took `ByteArrayLittleEndian` for a spin on a (new) micro for `String toHexDigits(byte)`, and that gives us ~4% (MacBook M1): Name Cnt Base Error Test Error Unit Diff% HexFormatBench.toHexDigits 15 1,943 ± 0,014 1,862 ± 0,009 us/op 4,1% (p = 0,000*) * = significant I'm not sure 4% is a large enough win on a micro to motivate the lookup-table based approach. I'd rather see us investigate if we could consolidate these overlapping utility classes (`HexFormat` and `HexDigits`) on a lookup-table free solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1710889268
