Community
Participate
Working Groups
I have put together some patches, that implement some thoughts about reducing matching-time by evaluating AndPointcuts and OrPointcuts lazily. This reduced matching costs in by about 30% in average on my tests. (testcase included) It works as follows: First enhancement: For an AndPointcut, "p && q", q is only evaluated if p matches already (or "maybe"). Same for OrPointcut respectively. Second enhancement: Every pointcut now comes with a method "double matchingCosts()" that should return a heuristic value of how expensive it would be to test if this pointcut matches. This helps the AndPointcut respectively OrPointcut to figure out which of the both pointcuts "left" or "right" should be matched first (first try the easier one). Thus by giving good heuristics on how likely a pointcut is going to match and how expensive such a matching would be, waeve time can again be improved. The matchingCosts() method is not yet implemented. That's up to you guys to find out what appropriate values would be. In a second approach I tried something even more powerful: Stateful AndPointcuts (resp. OrPointcuts): A stateful AndPointcut firstly evaluates the "easier" side. If it sees "yes" or "maybe", it fully evaluates. If it sees "no", it returns "no". Up till here this is as above. However, if it sees "never", it switches state to "never" match in general. So every subsequent tests do not need to be performed again. The drawback at the moment is that at the moment, no pointcut actually ever returns a FuzzyBooleanNever on matching, which seems a bit strange to me. As future work one could probably use term rewriting techniques to reduce something like "call(foo) && !call(foo)" to a never-matching pointcut. This should increase matching time for large projects again. At the moment however, the stateful implementation (which I provide for AndPointcut only here), seems to be less efficient that the first approach due to an indirection introduced by the call to the internal state object. I would be very interested in further discussion on that topic.
Created attachment 15606 [details] First, simple, approach including test-case
Created attachment 15607 [details] First approach again, here without overhead for testcase
Created attachment 15608 [details] Second, statful approach, for AndPointcut only, with testcase
> As future work one could probably use term rewriting techniques to > reduce something like "call(foo) && !call(foo)" to a never-matching > pointcut. This should increase matching time for large projects again. Small correction: Of course I meant *decrease* here, not *increase*.
A variation on this idea was implemented in Aj5 m1... forgot to close out this enh report at the time.
