On Thu, 9 Feb 2023 11:46:42 GMT, Eirik Bjorsnos wrote:
> > In addition to - or instead of - an `equals` shortcut then if coders are
> > the same we could use `ArraysSupport.mismatch` which should get similar
> > speed and help more generally.
>
> ..and if String had (an optimized) mismatch met
On Thu, 9 Feb 2023 11:39:18 GMT, Claes Redestad wrote:
> Yes, I'll file a PR to see if we can make `startsWith` a bit sharper
Thanks! I pushed the change to ZipCoder.compare.
> In addition to - or instead of - an `equals` shortcut then if coders are the
> same we could use `ArraysSupport.misma
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Thu, 9 Feb 2023 11:17:54 GMT, Eirik Bjorsnos wrote:
> It helps... a lot!
I guess an update to String.startsWith should be handled separately from this
PR.
If startsWith will be optimized, then I'm happy to update this PR to use
startsWith as you suggested. Then ZipCoder will speed up for f
On Thu, 9 Feb 2023 11:07:17 GMT, Claes Redestad wrote:
> Could be interesting to see if special-casing `startsWith` to call `equals`
> when possible would help:
It helps... a lot!
Benchmark (size) Mode CntScore Error Units
ZipFileGetEntry.getEntryHit
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Thu, 9 Feb 2023 10:05:06 GMT, Claes Redestad wrote:
> Should be a win and avoids the need for a new mismatch method here.
Interestingly, this is not a win:
PR:
Benchmark (size) Mode CntScore Error Units
ZipFileGetEntry.getEntryHit 512 avgt
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
On Wed, 8 Feb 2023 17:11:19 GMT, Claes Redestad wrote:
> Great! Extending coverage to provoke the issue on most charsets is good, and
> it should guard UTF-8 from regressing too - no?
It also guards UTFZipCoder from this particular regression, yes.
-
PR: https://git.openjdk.org/jd
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>> String
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
> API. This decoding step adds a significat cost to this metho
12 matches
Mail list logo
