Menu
▾
▴
springframework-developer
|
From: Rod J. <rod...@in...> - 2003-12-07 10:25:18
|
I've just checked in a simple "cflow"-style method matcher pointcut, that enables us to apply simple conditions such as "this call came from com.my.web.MyController class", or perhaps a particular method of such a class. It's 10-15 times slower to evaluate such a pointcut than a "normal" method matcher, because it's necessary to construct a new Throwable to analyse the stack trace (unless someone has a better idea!). However, it's still not *that* slow, and the cost wouldn't matter that much if it were done once per business invocation (my machine can do 4-5K complete invocations involving such evaluation per second, even running under a profiler). The performance issues can also be greatly reduced in composition with other pointcuts, assuming common sense is used with ordering. So if we want to advice "setter methods where the call came from wherever" the slow evaluation happens more rarely. See org.springframework.aop.support.ControlFlowPointcut. If you think this functionality is worthwhile, please try it out and--better still--help to improve it, as I don't have much more time for it. (It's pretty basic right now.) Regards, Rod |
|
From: Chris N. <ch...@si...> - 2003-12-07 10:51:24
|
Rod Johnson wrote: > I've just checked in a simple "cflow"-style method matcher pointcut, that > enables us to apply simple conditions such as "this call came from > com.my.web.MyController class", or perhaps a particular method of such a > class. > > It's 10-15 times slower to evaluate such a pointcut than a "normal" method > matcher, because it's necessary to construct a new Throwable to analyse > the stack trace (unless someone has a better idea!). There might be a better way if you restrict the cflow matching against classes you can proxy. For example, you could add an around advice to every method in com.my.web.MyController. The advice would increment a threadlocal before and decrement it after. To check if you're within the cflow you just see if the threadlocal value is greater than zero. This is probably more portable too since getStackTrace is 1.4 only (don't know if Spring requires 1.4), but then again ThreadLocals are pretty slow on anything below 1.4. Chris |
|
From: Rod J. <rod...@in...> - 2003-12-07 14:35:20
|
Chris At present it parses the stack trace itself, so it works in any version. However, the StaceTraceElement stuff from 1.4 may run faster: I'll do a benchmark shortly. If it does run _much_ faster, we might have to consider having different versions of that class for each JDK. I guess this is a broader issue though--I don't think we want two binary distributions for 1.0. Overall, Spring doesn't require 1.4 and we have plenty of users on 1.3. Regards, Rod ----- Original Message ----- From: "Chris Nokleberg" <ch...@si...> To: <spr...@li...> Sent: Sunday, December 07, 2003 10:51 AM Subject: [Springframework-developer] Re: Cflow > Rod Johnson wrote: > > I've just checked in a simple "cflow"-style method matcher pointcut, that > > enables us to apply simple conditions such as "this call came from > > com.my.web.MyController class", or perhaps a particular method of such a > > class. > > > > It's 10-15 times slower to evaluate such a pointcut than a "normal" method > > matcher, because it's necessary to construct a new Throwable to analyse > > the stack trace (unless someone has a better idea!). > > There might be a better way if you restrict the cflow matching against > classes you can proxy. For example, you could add an around advice to every > method in com.my.web.MyController. The advice would increment a threadlocal > before and decrement it after. To check if you're within the cflow you just > see if the threadlocal value is greater than zero. This is probably more > portable too since getStackTrace is 1.4 only (don't know if Spring requires > 1.4), but then again ThreadLocals are pretty slow on anything below 1.4. > > Chris > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <rod...@in...> - 2003-12-08 10:12:03
|
The Java 1.4 version, using Throwable.getStackTrace(), is a bit over twice as fast as the all-versions code based on parsing the results of printStackTrace(). It's probably a lot more memory efficient as well. This begs the question of how we can have both a 1.4 and 1.3 version--any thoughts on this? The 1.3 version is still fast enough to be viable for typical usage, so I don't think we can consider this a 1.4-only feature. Regards, Rod ----- Original Message ----- From: "Rod Johnson" <rod...@in...> To: <spr...@li...> Sent: Sunday, December 07, 2003 2:34 PM Subject: Re: [Springframework-developer] Re: Cflow > Chris > > At present it parses the stack trace itself, so it works in any version. > However, the StaceTraceElement stuff from 1.4 may run faster: I'll do a > benchmark shortly. > > If it does run _much_ faster, we might have to consider having different > versions of that class for each JDK. I guess this is a broader issue > though--I don't think we want two binary distributions for 1.0. > > Overall, Spring doesn't require 1.4 and we have plenty of users on 1.3. > > Regards, > Rod > > ----- Original Message ----- > From: "Chris Nokleberg" <ch...@si...> > To: <spr...@li...> > Sent: Sunday, December 07, 2003 10:51 AM > Subject: [Springframework-developer] Re: Cflow > > > > Rod Johnson wrote: > > > I've just checked in a simple "cflow"-style method matcher pointcut, > that > > > enables us to apply simple conditions such as "this call came from > > > com.my.web.MyController class", or perhaps a particular method of such a > > > class. > > > > > > It's 10-15 times slower to evaluate such a pointcut than a "normal" > method > > > matcher, because it's necessary to construct a new Throwable to analyse > > > the stack trace (unless someone has a better idea!). > > > > There might be a better way if you restrict the cflow matching against > > classes you can proxy. For example, you could add an around advice to > every > > method in com.my.web.MyController. The advice would increment a > threadlocal > > before and decrement it after. To check if you're within the cflow you > just > > see if the threadlocal value is greater than zero. This is probably more > > portable too since getStackTrace is 1.4 only (don't know if Spring > requires > > 1.4), but then again ThreadLocals are pretty slow on anything below 1.4. > > > > Chris > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: IBM Linux Tutorials. > > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Colin S. <col...@ex...> - 2003-12-08 13:08:54
|
It would add a small amount of overhead, but you could use reflection to try to use the Throwable.getStackTrace(), and on a failure, use the 1.3 code... Rod Johnson wrote: >The Java 1.4 version, using Throwable.getStackTrace(), is a bit over twice >as fast as the all-versions code based on parsing the results of >printStackTrace(). It's probably a lot more memory efficient as well. > >This begs the question of how we can have both a 1.4 and 1.3 version--any >thoughts on this? The 1.3 version is still fast enough to be viable for >typical usage, so I don't think we can consider this a 1.4-only feature. > >Regards, >Rod > >----- Original Message ----- >From: "Rod Johnson" <rod...@in...> >To: <spr...@li...> >Sent: Sunday, December 07, 2003 2:34 PM >Subject: Re: [Springframework-developer] Re: Cflow > > > > >>Chris >> >>At present it parses the stack trace itself, so it works in any version. >>However, the StaceTraceElement stuff from 1.4 may run faster: I'll do a >>benchmark shortly. >> >>If it does run _much_ faster, we might have to consider having different >>versions of that class for each JDK. I guess this is a broader issue >>though--I don't think we want two binary distributions for 1.0. >> >>Overall, Spring doesn't require 1.4 and we have plenty of users on 1.3. >> >>Regards, >>Rod >> >>----- Original Message ----- >>From: "Chris Nokleberg" <ch...@si...> >>To: <spr...@li...> >>Sent: Sunday, December 07, 2003 10:51 AM >>Subject: [Springframework-developer] Re: Cflow >> >> >> >> >>>Rod Johnson wrote: >>> >>> >>>>I've just checked in a simple "cflow"-style method matcher pointcut, >>>> >>>> >>that >> >> >>>>enables us to apply simple conditions such as "this call came from >>>>com.my.web.MyController class", or perhaps a particular method of such >>>> >>>> >a > > >>>>class. >>>> >>>>It's 10-15 times slower to evaluate such a pointcut than a "normal" >>>> >>>> >>method >> >> >>>>matcher, because it's necessary to construct a new Throwable to >>>> >>>> >analyse > > >>>>the stack trace (unless someone has a better idea!). >>>> >>>> >>>There might be a better way if you restrict the cflow matching against >>>classes you can proxy. For example, you could add an around advice to >>> >>> >>every >> >> >>>method in com.my.web.MyController. The advice would increment a >>> >>> >>threadlocal >> >> >>>before and decrement it after. To check if you're within the cflow you >>> >>> >>just >> >> >>>see if the threadlocal value is greater than zero. This is probably more >>>portable too since getStackTrace is 1.4 only (don't know if Spring >>> >>> >>requires >> >> >>>1.4), but then again ThreadLocals are pretty slow on anything below 1.4. >>> >>>Chris >>> >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: IBM Linux Tutorials. >>>Become an expert in LINUX or just sharpen your skills. Sign up for >>> >>> >IBM's > > >>>Free Linux Tutorials. Learn everything from the bash shell to sys >>> >>> >admin. > > >>>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click >>>_______________________________________________ >>>Springframework-developer mailing list >>>Spr...@li... >>>https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> >>> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: IBM Linux Tutorials. >>Become an expert in LINUX or just sharpen your skills. Sign up for IBM's >>Free Linux Tutorials. Learn everything from the bash shell to sys admin. >>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> > > > > >------------------------------------------------------- >This SF.net email is sponsored by: IBM Linux Tutorials. >Become an expert in LINUX or just sharpen your skills. Sign up for IBM's >Free Linux Tutorials. Learn everything from the bash shell to sys admin. >Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
