On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on > a `byte[]` subrange. It can profitably use the recently introduced > `ArraysSupport::vectorizedHashCode` method to see a speed-up, which > translates to a small but significant speed-up on `ZipFile` creation. > > Before: > > Benchmark (size) Mode Cnt Score Error Units > ZipFileOpen.openCloseZipFile 512 avgt 15 83007.325 ± 1446.716 ns/op > ZipFileOpen.openCloseZipFile 1024 avgt 15 154550.631 ± 2166.673 ns/op > > After: > > Benchmark (size) Mode Cnt Score Error Units > ZipFileOpen.openCloseZipFile 512 avgt 15 79512.902 ± 814.449 ns/op > ZipFileOpen.openCloseZipFile 1024 avgt 15 147892.522 ± 2744.017 ns/op Updated micro to vary entry sizes more to ensure we exercise the different code paths through the `hashCode` intrinsic. The new setup generates both longer and shorter entries than before, weighting up the average length a bit by increasing the spread. The longer entries see a proportionately larger speed-up, as expected since they benefit from vectorization. Removed some pointless randomness. Baseline: Benchmark (size) Mode Cnt Score Error Units ZipFileOpen.openCloseZipFile 512 avgt 15 98832.801 ± 2155.928 ns/op ZipFileOpen.openCloseZipFile 1024 avgt 15 187373.545 ± 2296.779 ns/op Patched: Benchmark (size) Mode Cnt Score Error Units ZipFileOpen.openCloseZipFile 512 avgt 15 85574.648 ± 920.477 ns/op ZipFileOpen.openCloseZipFile 1024 avgt 15 160493.277 ± 3450.928 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/12077
