On 09.01.20 19:01, Daniel.Sun wrote:
Hi Jochen,
I am still thinking about how to improve indy performance further in
the method overload cases, e.g.
```
def same(String obj) { return obj }
def same(int obj) { return obj }
def same(float obj) { return obj }
for (int i = 0; i < 100000; i++) {
[1, 1.0f, '1.0'].each { same(it) }
}
```
If we cache both receiver type and argument types, I find the
performance of this case can be improved a lot, but other cases performance
is reduced quite a bit too... so I am trying 2 levels cache: the 1st level
cache is the current cache for receiver type, its size is fixed as 16 by
default, and I want to add 2nd level cache is for caching argument types,
its size will be fixed as 16 by default too. The 2 caches are seperated, so
receiver types kept in 1st level cache will not be cleared, and 2nd level
cache can provide more hot candidates for better performance.
If you want to get the maximum performance then I would suggest to work
with the guards instead of falling back to a hashed map. The JVM can
quite efficiently check if x is of type X. So for example in the above
case I see something like this (Notes: ASCII art, MH(same(String) means
the method handle to invoke the method same with the parameter type
String, Guard(Integer) a guard checking for the argument type integer,
with positive case on the left and fallback on the right):
Guard(String)
/ \
MH(same(String) Guard(Float)
/ \
MH(same(float)) Guard(Integer)
/ \
MH(same(int)) Fallback to select
Ideally we would also take out the exception unrolling and the switch
point guards in the MH and have them in front of the first argument
chart. Heck in this case even the receiver check could be limited to be
done only once. In the end same(String) calls would perform with about
the same performance and same(int) calls would be slowest, but only by a
minimal margin. A hash based cache is never going to beat two simple
instanceof calls.
bye Jochen
