RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName

[Martin Buchholz]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190424/f1dc676f/attachment.html>