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

Reply via email to