RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName

[Ron Shapiro]

Ok, should I abandon this RFR then?

I can close the bug and link to Ivan's if so.

On Wed, Apr 24, 2019 at 11:12 PM Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> FYI.
>
> I filed en enhancement JDK-8222955
> <https://bugs.openjdk.java.net/browse/JDK-8222955> to do an optimization
> in somewhat broader case (when all strings are Latin1 encoded).
>
> The numbers look promising.  I'll send a RFR shortly.
>
> Hopefully, with this special case in place, having a separate branch for
> length-1 arguments wouldn't feel too distasteful :-)
> With kind regards,
>
> Ivan
>
> On 4/24/19 12:26 PM, Martin Buchholz wrote:
>
>
>
> On Wed, Apr 24, 2019 at 9:22 AM Ron Shapiro <ronshapiro at google.com> wrote:
>
>> I tried this, but it was 3.5x slower (320ms vs. 95ms) than the
>> removeExtension().replace(char, char) version. I imagine that's due to
>> something in the JIT for replace() vs. my personal StringBuilder usage.
>>
>
> String does get some hotspot intrinsics help, but for String.replace(char,
> char) specifically, it "cheats" by being able to create a String from a
> byte[] directly without using a public constructor.   So I can see why we
> would want to leverage String.replace(char, char).  Still, I'm surprised by
> 3.5x speed ratio.
>
> Anyways, this investigation supports trying to reuse the optimizations
> that make String.replace(char, char) so fast, and that are unavailable to
> ordinary java code, even though adding a special length-1 case is
> distasteful.
>
>
> --
> With kind regards,
> Ivan Gerasimov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190425/b8f3bae2/attachment.html>