>yes, I also agree that such instructions are needed. I also have some very >long build times.
I also agree, but I've only got one pair of hands :) The timers for Thomas were hacked in, and need some work before I would leave them more permanently in place, but I plan to do that, at least for a few of the high level ones. As I've shown with Thomas, I'm more than willing to work with anyone on performance issues if they will work with me - and Thomas did just that. Reporting 'its slow' and then not following it through to help me resolve it isn't helpful (I'm not criticizing anyone on the thread, I'm just reminded of a bug I currently have open where the only information I can get out of the raiser is that 1.6.5 is slower than 1.6.1 - no pointcut specifics or application characteristics - I can't work without that info, I don't knowingly make things slower so clearly when it slows down it is something I don't know about). Thomas was particularly unfortunate. He stressed the *only* xlint that costs CPU to compute, the rest (at warning level or higher) are just put out during compilation/weaving for minimal cost. Given that no-one ever understands that xlint either, I'll probably turn it to OFF as default. Turning xlints up to warning or higher is recommended practice (errm, but don't ask me where that is written down!) for diagnosing why your pointcut doesn't match when you expect it to. Just worth repeating I think, if you have performance problems and you really think it can't be right, then raise a bug - please don't assume because you are hitting an issue all the time that I know about it. Andy 2009/10/12 Simone Gianni <[email protected]>: > I was also thinking that new metrics Andy added to the replacement jars for > Thomas could be left there, eventually with a switch for activating them, > and proper explanations written somewhere to interpret that output. For > example : > > fastShadowMatching > This indicates how much time the weaver is spending in fast-matching. Fast > matching is an optimized matching algorithm that takes into account more > specific point cuts before generic ones, so that it can determine faster if > a given method in a given class matches or not. > If you see that a small amount of time is spent into this cycle in respect > to total build time, then probably your point cuts are very generic and > could be scoped better. In this case scoping at class level is what is > needed. > Some ways to scope your point cuts so that fast matching can be used are : > > - Include a within(Type) along execute() pointcuts. > execute() is by definition generic. In fact, execute(public void > MyType.setSomething(int)) includes also execution of setSomething in every > subclass of MyType. If you intend to only match execution of setSomething in > MyType and not also in subclasses you can add within(MyType). > - what else? > > > Also, adding a "performance XLint" option(s), disabled by default, could be > a useful tool to see if/where the weaver is having performance problems, > like for example being unable to use fast matching, or other places where > possible optimizations are not engaged because of programmer's inexperience. > > Just my 2 cents. > > Simone > > > Simone Gianni wrote: >> >> Ciao Bepi, >> yes, I also agree that such instructions are needed. I also have some very >> long build times. >> >> Simone >> >> Bepi Esposito Vingiano wrote: >>> >>> Hi to all. >>> I've followed the 'Overall problem with AJDT performance' thread with >>> interest but. >>> I'm working on a big project and trying to use aspectj and AJDT. >>> It would be very useful to have a 'guide to optimization' for building >>> inside Eclipse with all the settings to make the build process better (in >>> terms of time spent). >>> I have times of 3-4 minutes when building the project. >>> Ciao >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> aspectj-users mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> >> >> > > > -- > Simone Gianni CEO Semeru s.r.l. Apache Committer > http://www.simonegianni.it/ > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
