On Fri, 20 Jan 2023 11:25:22 GMT, Lance Andersen <lan...@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> I was experimenting with varying the entry names length to see what - if any - impact it had and saw a small effect on the micro. It does make more sense to vary lengths now that very long names will take different paths in the vectorized intrinsic. I'll see what I can do without overengineering this. ------------- PR: https://git.openjdk.org/jdk/pull/12077
