RFR: 8343559: Optimize Class.getMethod(String, Class<?>...) for methods with no-arg [v2]

Chen Liang liach at openjdk.org
Wed Nov 6 17:38:28 UTC 2024


On Wed, 6 Nov 2024 17:28:54 GMT, jengebr <duke at openjdk.org> wrote:

>> I benchmarked variations on this and got some surprises.  The noArg change was removed prior to any experiments, so this is strictly the `matches()` optimization.
>> 
>> Base case (no PR):
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    94.586 ±  0.733  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    75.587 ± 11.300  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   215.794 ±  7.713  ns/op
>> ClassGetMethod.getIntfNoArg        avgt    6   200.418 ±  4.352  ns/op
>> ClassGetMethod.getNoSuchMethod     avgt   10  2207.928 ± 49.767  ns/op
>> ClassGetMethod.getSuperFiveArg     avgt    6   190.142 ±  1.995  ns/op
>> ClassGetMethod.getSuperNoArg       avgt    6   153.943 ±  7.491  ns/op
>> 
>> 
>> With `Arrays.equals()`, then name:
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    82.949 ±  7.614  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    98.248 ± 11.482  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   204.604 ±  5.656  ns/op
>> ClassGetMethod.getIntfNoArg        avgt    6   225.582 ±  5.238  ns/op
>> ClassGetMethod.getNoSuchMethod     avgt   10  2216.038 ± 48.732  ns/op
>> ClassGetMethod.getSuperFiveArg     avgt    6   172.416 ±  3.211  ns/op
>> ClassGetMethod.getSuperNoArg       avgt    6   138.102 ± 16.215  ns/op
>> 
>> (faster in some cases, slower in others)
>> 
>> With paramCount, then name, then Arrays.equals():
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    95.117 ±  1.574  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    77.915 ± 10.294  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   193.514 ±  4.611  ns/op
>> ClassGetMethod.getIntfNoArg        avgt    6   205.957 ±  4.475  ns/op
>> ClassGetMethod.getNoSuchMethod     avgt   10  2234.166 ± 51.249  ns/op
>> ClassGetMethod.getSuperFiveArg     avgt    6   164.650 ±  3.689  ns/op
>> ClassGetMethod.getSuperNoArg       avgt    6   128.969 ±  4.442  ns/op
>> 
>> (faster or neutral in all cases)
>> 
>> With paramCount, then name, then custom loop:
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    64.802 ±  4.504  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    51.998 ±  5.645  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   194.252 ±  7.759  ns/op
>> ClassGetMethod.getIn...
>
> I don't like the style of a custom loop rather than `Arrays.equals()` but there is a perf benefit to it.  Curious what you think?

Sure, moving param count ahead is fine.  Note that `Arrays.equals` is subject to profile pollution at runtime, so the benchmark results might not be applicable in practice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1831459646


More information about the core-libs-dev mailing list