Summary: | dflow pointcut | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Rohit Sethi <rklists> |
Component: | Runtime | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | aclement, eric |
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
URL: | www.graco.c.u-tokyo.ac.jp/~masuhara/papers/aplas2003.pdf | ||
Whiteboard: |
Description
Rohit Sethi
2008-08-11 13:43:04 EDT
Does anybody know if a performance evaluation of this feature has been done in the meantime? If I remember correctly then the evaluation of the pointcut could potentially be very expensive without (whole-program?) optimizations. I haven't seen any performance evaluations - admittedly I've only done simple google searching. My guess is that you're correct and performance impact is very high; would clearly documenting (e.g. in the programmers guide) the potential performance impact be an adequate compensating control for this? (In reply to comment #2) > would clearly documenting (e.g. in the programmers guide) the > potential performance impact be an adequate compensating control for this? I guess that depends on how high the overhead really is. If it is prohibitively high then I wonder whether it's worth the effort at all. We should maybe ask Hidehiko for his opinion. (In reply to comment #3) > (In reply to comment #2) > > would clearly documenting (e.g. in the programmers guide) the > > potential performance impact be an adequate compensating control for this? > > > I guess that depends on how high the overhead really is. If it is prohibitively > high then I wonder whether it's worth the effort at all. We should maybe ask > Hidehiko for his opinion. > I tried to contact Hidehiko earlier about implementing the dflow pointcut in AspectJ and didn't get any response. Perhaps you guys will be more successful given that you are developers for AspectJ. |