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

jengebr duke at openjdk.org
Wed Nov 6 17:31:34 UTC 2024


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

>> src/java.base/share/classes/java/lang/PublicMethods.java line 108:
>> 
>>> 106:                                Class<?>[] ptypes) {
>>> 107:             // check for matching param types length, then name, then param type equality
>>> 108:             return method.getParameterCount() == ptypes.length &&
>> 
>> Length check is already present in `equals`.  If you want this fast path, I think moving arrays equals check first is better.
>
> 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.getIntfNoArg        avgt    6   199.110 ±  4.163  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   1...

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?

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

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


More information about the core-libs-dev mailing list