I looked into another direction. (Or rather two). First I replaced the HashMap by an GrowingMap that uses an Array(List) backed Map implementation up until 10 elements and a HashMap later. As I assume that a single mixin will seldom have more than 10 methods this should speed up things considerably. On my machine it went up from 2 mio to 3.3 mio invocations / s.
Secondly. I looked at the implementation of method.equals and it seems to be quite expensive (imho). I started replacing method with a MethodInfo object in CompositeModel but it didn't work out as creating the MethodInfo again and again costs to much. If the method info was the object that would be handled inside of qi4j then the benefit would appear as it wouldn't have to be created all the time. (Additional benefit would be that it can handle serialization of methods and so no separate method-map implementation would be needed anymore. If you think this is useful I'll submit it into the repo (the first one) Michael Am 05.03.2009 10:02 Uhr, schrieb Rickard Öberg: > Niclas Hedhman wrote: >> And if it is a larger invocation stack the benefit will diminish? > > Percentage-wise, sure. This was for a plain method invocation directly > to a static mixin, with no concerns. Anything else than that will lower > the numbers. > > /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
