.
From: core-libs-dev on behalf of Johannes
Döbler
Sent: Thursday, July 24, 2025 12:33 PM
To: core-libs-dev@openjdk.org
Subject: Re: String.charAt vs StringBuilder.charAt performance
Hi Brett,
I ran your benchmark on a Windows11 Pro 24H2 / ARM64 / JDK 21 system and can
reproduce your
k.org
*Subject:* Re: String.charAt vs StringBuilder.charAt performance
Updating to have different test methods for each
representation did remove the difference for the non-ascii
String case for the jdk 21+ releases.
However, the ascii (latin) strings are still s
Hi,
the errors are so large that I'd dare to say that the measurements are
unreliable.
On 2025-07-22 13:44, Brett Okken wrote:
It does look like this is windows specific. If I run on WSL, I get
results similar to your linux-x64:
Benchmark (data) Mode Cnt Score
>> Chen
>> --
>> *From:* core-libs-dev on behalf of
>> Brett Okken
>> *Sent:* Monday, July 21, 2025 4:01 PM
>> *To:* Roger Riggs
>> *Cc:* core-libs-dev@openjdk.org
>> *Subject:* Re: String.charAt vs StringBuilder.charAt p
t; --
> *From:* core-libs-dev on behalf of Brett
> Okken
> *Sent:* Monday, July 21, 2025 4:01 PM
> *To:* Roger Riggs
> *Cc:* core-libs-dev@openjdk.org
> *Subject:* Re: String.charAt vs StringBuilder.charAt performance
>
> Updating to have dif
which contribute to
this slowdown, instead of a problem with the C2 IR.
Chen
From: core-libs-dev on behalf of Brett Okken
Sent: Monday, July 21, 2025 4:01 PM
To: Roger Riggs
Cc: core-libs-dev@openjdk.org
Subject: Re: String.charAt vs StringBuilder.charAt perfor
Updating to have different test methods for each representation did remove
the difference for the non-ascii String case for the jdk 21+ releases.
However, the ascii (latin) strings are still slower with String than
StringBuilder.
How does C2 then handle something like StringCharBuffer wrapping a
C
Hi Brett,
I'd suggest separate initialization and test methods for the two cases
to get more reliable numbers.
By using @Trial and using a common field for the test data, I think you
have handicapped C2.
The training runs JMH does to warm up C2 are 'seeing' two different
types for the value
> output labeled as StringBuffer but the jmh creates StringBuilder.
Ugh - sorry about that. But yes - this is about StringBuilder vs String.
> I would not be surprised that C2 has more optimizations for String than
for StringBuilder.
If that were true, it would not surprise me. However, these t
Hi Brett,
The labeling of the output is confusing, the test output labeled as
StringBuffer but the jmh creates StringBuilder.
(StringBuffer methods are all synchronized and could explain why they
are slower).
Also, I would not be surprised that C2 has more optimizations for String
than for S
Making sequence a local variable does improve things (especially for
ascii), but a substantial difference remains. It appears that the
performance difference for ascii goes all the way back to jdk 11. The
difference for non-ascii showed up in jdk 21. I wonder if this is related
to the index checks?
Without looking at C2 IRs, I think there are a few potential culprits we
can look into:
1. JDK-8351000 and JDK-8351443 updated StringBuilder
2. Sequence field is read in the loop; I wonder if making it an explicit
immutable local variable changes anything here.
On Sat, Jul 19, 2025 at 2:34 PM Bret
I was looking at the performance of StringCharBuffer for various
backing CharSequence types and was surprised to see a significant
performance difference between String and StringBuffer. I wrote a
small jmh which shows that the String implementation of charAt is
significantly slower than StringBuil
13 matches
Mail list logo
