Actions
Feature #3291
closedSpeed up CIF essentially
Start date:
07/26/2012
Due date:
% Done:
0%
Estimated time:
Published in build:
Description
Recently we have noticed that CIF processes a huge amount of pointcuts for a large program inefficiently. This almost doesn't depend on a representation of pointcuts: either in separate advices or in one advice which join pointcuts with help of '||'.
I think about this and profile CIF a bit. So there are about 20 thousands of ldv_match_cp() calls and about 50 millions of repeated calls of this function for driver usb/serial/aircable.c and model 119_1a. It means that 20 thousands join points in the driver were analyzed by CIF. But, because of the composite pointcut represents disjunction of about 5 thousands of primitive pointcuts, CIF has checked each of join point against 5 thousands of primitive pointcuts. Generally speaking, this should be done, since the given join point can be matched with one of this primitive pointcut. But this time CIF works inefficiently! I guess, that the most of join points analyzed aren't function call, while the model huge composite pointcut consists just of primitive pointcuts on function calls.
To optimize CIF, we can:
I think about this and profile CIF a bit. So there are about 20 thousands of ldv_match_cp() calls and about 50 millions of repeated calls of this function for driver usb/serial/aircable.c and model 119_1a. It means that 20 thousands join points in the driver were analyzed by CIF. But, because of the composite pointcut represents disjunction of about 5 thousands of primitive pointcuts, CIF has checked each of join point against 5 thousands of primitive pointcuts. Generally speaking, this should be done, since the given join point can be matched with one of this primitive pointcut. But this time CIF works inefficiently! I guess, that the most of join points analyzed aren't function call, while the model huge composite pointcut consists just of primitive pointcuts on function calls.
To optimize CIF, we can:
- Derive some information for the given composite pointcut on the basis of its primitive pointcuts at the aspect parsing stage. For instance, we can say that the given composite pointcut is disjunction of just primitive pointcuts on function calls. Then when we will analyze some join point that isn't a function call we will be able quickly understand whether the given composite pointcut can match it or not. With careful aspect developing (e.g. if one will combine all similar primitive pointcuts together with help of disjunction) it will speed up CIF essentially.
- Analyze join points distribution. I guess that the most of join points are related with variable manipulations. But we haven't models that use set and get poincuts (as well as other associated with variable manipulations)! Thus we can simply omit analysis of variable manipulations in CIF (conditionally). However this approach may be absolutely useless if one will use at least one set or get pointcut in general kernel model that will be included in each rule model.
- Use both these optimizations.
Files
Actions