Hi,
to say this first I am currently working on several improvements in
indy, but progress is really slow. Just yesterday I learned something
new I have now to think about how to make it part of the overall
construction.
Just for clarification: callsite is a place of a method call. foo.bar()
has a callsite that calls the method bar. foo.bar(); foo.bar2(); is two
call sites and 10.times {foo.bar()} has only 1 callsite for bar, which
will be visited multiple times.
One central problem to indy is that it is quite expensive to construct.
Not each time, mostly the first time. All my tests show that cost in our
runtime generated callsites in old Groovy are far worse when you look at
them in isolation. But if you go with thousands of callsites the
runtime generated versions are basically the same requiring basically no
recreation, while indy currently does. This then results in a longer
initial time spend. If your application has many callsites that are
visited only a few times the overall performance will be suffering a bit.
Then there is the caching in the callsite itself. For simple cases this
works, but there are some cases where our caching results in the
callsite needed recreation all the time. And as I stated before this is
not cheap. Thus the two problems are a bit related actually. Especially
in the static method calls I noticed some problems.
Now I have not enough information about Gabriel's specific problems. It
would actually be nice to have more details and trying to analyze what
exactly goes wrong here. But in case of MG I think it is both, specific
static method call patterns and initial costs.
bye Jochen
