Feature #3291
closedSpeed up CIF essentially
0%
Description
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
Updated by Evgeny Novikov about 11 years ago
- File 0123.aspect.i.bz2 added
- File cpcihp_zt5550.c.macroinstrumented.bz2 cpcihp_zt5550.c.macroinstrumented.bz2 added
Ilya Shchepetkov detected one more example of very slow work of Aspectator. Corresponding files were attached.
Updated by Evgeny Novikov almost 11 years ago
- File 0123.aspect.i.tar.xz 0123.aspect.i.tar.xz added
Add non broken aspect file.
Updated by Ilya Shchepetkov almost 11 years ago
- File callgrind.out.4746 callgrind.out.4746 added
- Status changed from New to Open
- Assignee changed from Evgeny Novikov to Ilya Shchepetkov
Added file with some profile information.
Updated by Ilya Shchepetkov almost 11 years ago
In feature-3291 branch I speeded up aspectator's work in case of large generated aspects (like one with might_sleep functions). However, I believe the work is far from complete.
Updated by Evgeny Novikov almost 11 years ago
People optimizes compilers for decades, but still has TODOs. Aspectator is a compiler, so don't worry!
Updated by Evgeny Novikov almost 11 years ago
Actually, to resolve this feature request we just need to check whether your optimizations work for 119_1a specification. And if so it can be closed after merge to the mainline branch.
Other optimizations should be treated in other feature requests.
Updated by Evgeny Novikov over 10 years ago
- Status changed from Open to Resolved
Unfortunately mentioned tests weren't performed, so don't close the issue although code was merged to master in d1a3cd1.
Updated by Evgeny Novikov over 10 years ago
- Assignee changed from Ilya Shchepetkov to Evgeny Novikov
Updated by Ilya Shchepetkov over 10 years ago
- Status changed from Resolved to Closed
Fortunately mentioned tests were performed. 119_1a specification works fine.
Updated by Evgeny Novikov over 10 years ago
- Assignee changed from Evgeny Novikov to Ilya Shchepetkov
You did it! But what about #3323?