> This change optimizes the runtime of `Class.getMethod(String, Class[])` by
> reducing the cost of the existing search logic. Specifically, while
> iterating across each Method to find a match (existing logic) it now compares
> parameter count before checking method name. This check is substa
On Wed, 6 Nov 2024 17:35:36 GMT, Chen Liang wrote:
>> 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
On Wed, 6 Nov 2024 17:35:36 GMT, Chen Liang wrote:
> Note that Arrays.equals is subject to profile pollution at runtime, so the
> benchmark results might not be applicable in practice.
Good point, thank you. Should I stick with `Arrays.equals()` on the basis that
it's more intuitive, and the
On Wed, 6 Nov 2024 17:28:54 GMT, jengebr 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 C
On Wed, 6 Nov 2024 17:28:08 GMT, jengebr 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:
On Wed, 6 Nov 2024 15:19:31 GMT, Chen Liang wrote:
>> jengebr has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Optimizing filter logic by internalizing loop
>> - Enhancing benchmark + tests with additional 5-arg cases
>> - Removing
> This change optimizes the runtime of `Class.getMethod(String, Class[])` in
> two ways:
>
> 1. While iterating across each Method to find a match (existing logic) it now
> compares parameter count before checking method name. This check is
> substantially faster.
> 2. While iterating (existin
On Wed, 6 Nov 2024 15:20:42 GMT, Chen Liang wrote:
>> This change optimizes the runtime of `Class.getMethod(String, Class[])`
>> in two ways:
>>
>> 1. While iterating across each Method to find a match (existing logic) it
>> now compares parameter count before checking method name. This check
On Wed, 6 Nov 2024 14:15:42 GMT, jengebr wrote:
> This change optimizes the runtime of `Class.getMethod(String, Class[])` in
> two ways:
>
> 1. While iterating across each Method to find a match (existing logic) it now
> compares parameter count before checking method name. This check is
> s
On Wed, 6 Nov 2024 14:15:42 GMT, jengebr wrote:
> This change optimizes the runtime of `Class.getMethod(String, Class[])` in
> two ways:
>
> 1. While iterating across each Method to find a match (existing logic) it now
> compares parameter count before checking method name. This check is
> s
On Wed, 6 Nov 2024 14:15:42 GMT, jengebr wrote:
> This change optimizes the runtime of `Class.getMethod(String, Class[])` in
> two ways:
>
> 1. While iterating across each Method to find a match (existing logic) it now
> compares parameter count before checking method name. This check is
> s
This change optimizes the runtime of `Class.getMethod(String, Class[])` in
two ways:
1. While iterating across each Method to find a match (existing logic) it now
compares parameter count before checking method name. This check is
substantially faster.
2. While iterating (existing logic) if th
12 matches
Mail list logo
