RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName

[Ivan Gerasimov]

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 
> <mailto: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/20190424/9f8d7003/attachment-0001.html>