On Thu, 27 Jun 2024 16:05:09 GMT, Chen Liang <li...@openjdk.org> wrote:

>> This PR attains a speed-up on some microbenchmarks by simplifying how we 
>> build up the MH combinator tree shape
>> (only use prependers with prefix, always add a suffix to the newArray 
>> combinator), then simplifying/inlining some of the code in the helper 
>> functions. 
>> 
>> Many simple concatenation expressions stay performance neutral, while the 
>> win comes from enabling C2 to better optimize more complex shapes 
>> (concat13String, concatMix4String, concatConst6String see relatively large 
>> improvements):
>> 
>> 
>> Name                                    Cnt     Base     Error      Test     
>> Error  Unit  Change
>> StringConcat.concat13String              50   66.380 ±   0.189    53.017 ±   
>> 0.241 ns/op   1.25x (p = 0.000*)
>> StringConcat.concat4String               50   13.620 ±   0.053    12.382 ±   
>> 0.089 ns/op   1.10x (p = 0.000*)
>> StringConcat.concat6String               50   17.168 ±   0.070    16.046 ±   
>> 0.064 ns/op   1.07x (p = 0.000*)
>> StringConcat.concatConst2String          50    9.820 ±   0.081     8.158 ±   
>> 0.041 ns/op   1.20x (p = 0.000*)
>> StringConcat.concatConst4String          50   14.938 ±   0.124    12.800 ±   
>> 0.049 ns/op   1.17x (p = 0.000*)
>> StringConcat.concatConst6Object          50   56.115 ±   0.288    54.046 ±   
>> 0.214 ns/op   1.04x (p = 0.000*)
>> StringConcat.concatConst6String          50   19.032 ±   0.073    16.213 ±   
>> 0.093 ns/op   1.17x (p = 0.000*)
>> StringConcat.concatConstBoolByte         50    8.486 ±   0.066     8.556 ±   
>> 0.050 ns/op   0.99x (p = 0.004*)
>> StringConcat.concatConstInt              50    8.942 ±   0.052     7.677 ±   
>> 0.029 ns/op   1.16x (p = 0.000*)
>> StringConcat.concatConstIntConstInt      50   12.883 ±   0.070    12.431 ±   
>> 0.070 ns/op   1.04x (p = 0.000*)
>> StringConcat.concatConstString           50    7.523 ±   0.050     7.486 ±   
>> 0.044 ns/op   1.00x (p = 0.058 )
>> StringConcat.concatConstStringConstInt   50   11.961 ±   0.032    11.699 ±   
>> 0.049 ns/op   1.02x (p = 0.000*)
>> StringConcat.concatEmptyConstInt         50    7.778 ±   0.038     7.723 ±   
>> 0.037 ns/op   1.01x (p = 0.000*)
>> StringConcat.concatEmptyConstString      50    3.506 ±   0.026     3.505 ±   
>> 0.015 ns/op   1.00x (p = 0.930 )
>> StringConcat.concatEmptyLeft             50    3.573 ±   0.075     3.518 ±   
>> 0.057 ns/op   1.02x (p = 0.044 )
>> StringConcat.concatEmptyRight            50    3.713 ±   0.049     3.622 ±   
>> 0.053 ns/op   1.02x (p = 0.000*)
>> StringConcat.concatMethodConstString     50    7.418 ±   0.030     7.478 ±   
>> 0.066 ns/op   0.99x (p...
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 157:
> 
>> 155:             }
>> 156:             index -= prefix.length();
>> 157:             prefix.getBytes(buf, index, String.LATIN1);
> 
> Since we are now passing in a lot of empty prefix, I wonder how this call is 
> elided; is there some specific JIT intrinsic? The java code has no shortcut 
> for `length == 0`.

Remember that the prefixes are all constants and bound into the MH at each call 
site, so one view is that this PR is mostly about tickling the code into 
something that just-so happens to be easier for the JIT to swallow

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1657513167

Reply via email to