Best practices in optimization
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Best practices in optimization
by Bepi Esposito Vingiano
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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 aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: Best practices in optimization
by Simone Gianni-2
::
Rate this Message:
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 > aspectj-users@... > 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 aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: Best practices in optimization
by Simone Gianni-2
::
Rate this Message:
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 >> aspectj-users@... >> 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 aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: Best practices in optimization
by Andy Clement
::
Rate this Message:
>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 <simoneg@...>: > 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 >>> aspectj-users@... >>> 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 > aspectj-users@... > https://dev.eclipse.org/mailman/listinfo/aspectj-users > aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: Best practices in optimization
by Simone Gianni-2
::
Rate this Message:
Hi Andy,
do you think wiki.eclipse.org can be used to setup a page for listing known performance enhancements? I'm logged in it right now and can try to write such a page. I didn't know of the speed-up using within() along with execution() can offer, until it popped up here on the list, but things on the list will get lost if not collected somewhere. That's the essence of this thread. Simone Andy Clement wrote: >> 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 <simoneg@...>: > >> 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 >>>> aspectj-users@... >>>> 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 >> aspectj-users@... >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> >> > _______________________________________________ > aspectj-users mailing list > aspectj-users@... > 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 aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
|
|
|
AspectJ wiki pages (was: Best practices in optimization)
by Simone Gianni-2
::
Rate this Message:
Hi all,
I've created some AspectJ pages on the Eclipse wiki. You can find it here http://wiki.eclipse.org/AspectJ . Obviously those pages are open to everyone for cooperation. The purpose is writing there the shared knowledge currently present on the list. I tried to summarize build time optimizations described here on the list, have a look if you find some answers and feel free to fix any mistake I've made. I also wrote down some explanations and common solutions to Lint messages, at least the ones I know, and what I found on the list about runtime optimizations. Keeping an informal and accessible style sounded the best option for a wiki. Simone Bepi Esposito Vingiano wrote: > Hi Simone, Andy and all. > Andy I fully agree with you. Collaboration is the key. > Indeed I have no problems with aspectj (times are reasonable), only if > I had some initial tips and tricks maybe I could make my build time > better. > For example: > I haven't understood if the include clause in aop.xml have influence > inside eclipse. Can it help? > Then I have used the within in joinpoint definition but it seems to me > that the building times are the same. > I have used also the withincode. It can help? > While building I see the names of the classes woven. I see many names > that apparently should not be interested > by my aspects. > Then I'm asking to myself: maybe I must consider some other settings? > I begun the thread with these questions in my mind. > I'm ready to collaborate for testing and from writing in the wiki if > it can help some other people. No problem :) > (sorry for my English. I'm from Italy) > Ciao > > Bepi > ------------------------------------------------------------------------ > > _______________________________________________ > aspectj-users mailing list > aspectj-users@... > 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 aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: AspectJ wiki pages (was: Best practices in optimization)
by Andy Clement
::
Rate this Message:
Thanks for kicking this off Simone. I'll comment when I can and maybe
once I get the timers in place properly we can include a suitable diagnostic section related to them. To answer some of Bepis questions: >> I haven't understood if the include clause in aop.xml have influence >> inside eclipse. Can it help? Support for aop.xml configuration in the IDE (eclipse) for compilation is in the very early stages. It is more for helping you get your aop.xml right rather than trying to make weaving faster. The include clause in there will currently not be respected for ITDs, but only for advice (as this is a work in progress). But really an include clause is just another way to write a within() pointcut. >> Then I have used the within in joinpoint definition but it seems to me >> that the building times are the same. that is what I would expect >> I have used also the withincode. It can help? I don't believe it implements fastMatch - but I think it probably could. I'd imagine withincode making a difference if you are matching a lot of call joinpoints. >> While building I see the names of the classes woven. I see many names that >> apparently should not be interested by my aspects. What you see is a message that says "woven X" - this means it has been through the weaver, it does not mean the type was changed at all. I really should change that message as it gives the wrong impression. A suitable within() clause will have caused the weaver to return immediately and not change the type. Whether it actually got modified is reflected in weave info messages and the advice markers you see after compilation. >> Then I'm asking to myself: maybe I must consider some other settings? >> I begun the thread with these questions in my mind. Always try to include a scoping pointcut if possible, they are cheaper to evaluate even thought they don't all implement fast match (yet). Andy 2009/10/13 Simone Gianni <simoneg@...>: > Hi all, > > I've created some AspectJ pages on the Eclipse wiki. You can find it here > http://wiki.eclipse.org/AspectJ . > > Obviously those pages are open to everyone for cooperation. The purpose is > writing there the shared knowledge currently present on the list. > > I tried to summarize build time optimizations described here on the list, > have a look if you find some answers and feel free to fix any mistake I've > made. > > I also wrote down some explanations and common solutions to Lint messages, > at least the ones I know, and what I found on the list about runtime > optimizations. > > Keeping an informal and accessible style sounded the best option for a wiki. > > > Simone > > Bepi Esposito Vingiano wrote: >> >> Hi Simone, Andy and all. >> Andy I fully agree with you. Collaboration is the key. >> Indeed I have no problems with aspectj (times are reasonable), only if I >> had some initial tips and tricks maybe I could make my build time better. >> For example: >> I haven't understood if the include clause in aop.xml have influence >> inside eclipse. Can it help? >> Then I have used the within in joinpoint definition but it seems to me >> that the building times are the same. >> I have used also the withincode. It can help? >> While building I see the names of the classes woven. I see many names that >> apparently should not be interested >> by my aspects. >> Then I'm asking to myself: maybe I must consider some other settings? >> I begun the thread with these questions in my mind. >> I'm ready to collaborate for testing and from writing in the wiki if it >> can help some other people. No problem :) >> (sorry for my English. I'm from Italy) >> Ciao >> Bepi >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@... >> 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 > aspectj-users@... > https://dev.eclipse.org/mailman/listinfo/aspectj-users > aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
