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 test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 69: > 67: > 68: ename += "long-entry-name-" + (random.nextInt(90000) + > 10000) + "-" + i; > 69: zos.putNextEntry(new ZipEntry(ename)); Would it be worth to add some random sized data when the entries are created to allow for getting a bit more insight, or perhaps do that in a separate benchmark> ------------- PR: https://git.openjdk.org/jdk/pull/12077