RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName

Martin Buchholz martinrb at google.com
Wed Apr 24 19:26:07 UTC 2019

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

More information about the compiler-dev mailing list