On Fri, 20 Jan 2023 16:42:47 GMT, Lance Andersen wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Vary dir and entry name lengths across a wider spread, keeping most
>> entries short but making the longest paths
On Fri, 20 Jan 2023 12:19:50 GMT, Claes Redestad 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
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad 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 s
> `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.
>
>
On Fri, 20 Jan 2023 11:25:22 GMT, Lance Andersen 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
On Fri, 20 Jan 2023 11:10:13 GMT, Alan Bateman wrote:
> > FWIW the micro is derived from the sibling `ZipFileGetEntry` micro in the
> > same directory. It's not exactly necessary for this use case to add such a
> > benchmark, but I think there's value in verifying that optimizing
> > `checkedH
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad 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 s
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad 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 s
On Thu, 19 Jan 2023 09:46:12 GMT, Claes Redestad wrote:
> FWIW the micro is derived from the sibling `ZipFileGetEntry` micro in the
> same directory. It's not exactly necessary for this use case to add such a
> benchmark, but I think there's value in verifying that optimizing
> `checkedHash` i
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad 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 s
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad 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 s
`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:
Ben
12 matches
Mail list logo
