Bug 297987 - Construction and usage of a pointcut parser can be expensive
Summary: Construction and usage of a pointcut parser can be expensive
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.6.7   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-16 13:37 EST by Andrew Clement CLA
Modified: 2010-01-12 19:58 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Clement CLA 2009-12-16 13:37:13 EST
In some environments, a developer wants to exploit AspectJ by parsing pointcuts of their own construction (pointcuts not necessarily coming from a source file or aop.xml).  In these situations there is a need to conjure up a pointcut parser and use it.  This needs the following pieces of AspectJ to be performant:

- construction of a pointcut parser
- parsing of a pointcut expression string

Under Spring IDE we are seeing some situations where construction is expensive (500ms>1000ms).  This appears to be due to the setClassLoader call that happens internally whilst building the parser and the ReflectionWorld that causes to come into existence.  My own tests show no such problem (using the context classloader in a JUnit test) but under Spring IDE the context classloader is a little more 'full' of stuff.  The messyness of the classloader ought to be irrelevant when constructing a world, but it appears to have an impact.
Comment 1 Andrew Clement CLA 2010-01-12 19:58:41 EST
for now it is being tackled in a different way by partially caching the types loaded.  the speed up with that change means this isn't as urgent as it was.