Re: Optimising Variable to reduce instantiation overhead

On Sun 12 March 2006 21:28, Lane Sharman wrote:
> Hi Alex,
>
> I would post the fixes one by one or send them to me as a zip.

I've forwarded you the blocked email directly.

> I am the lead release admin and I will look at them myself and wait for
> some more feedback before dropping them into cvs head.

OK.

> Also, do you want to do some development to webmacro as a cvs committer?

That would definitely make things a bit easier to keep track of what things 
are experimental (for me) and what I've sent to the list.  
Do you have standard formats for commit messages etc?  
and does everything happen in a single branch or does each developer work on 
their own branch? 

I don't envisage doing anything particularly radical, and I'm mainly 
interested in optimising and fine tuning existing algorithms and memory usage 
- webmacro is currently taking more overhead than my backend application 
server so it is the next obvious target for a bit of selective tweaking.

Are there any standard load tests for different elements of webmacro that 
measure performance rather than correctness?  
Is this something that would be useful to put together so that we can evaluate 
performance related versions against each other?
I'm very much aware that I'm only testing against my usage patterns, and 
although I'm pretty sure that I'm not slowing anything down for other people, 
there may be many other cases that I'm not touching on that could bring 
useful tweaks to move the process forwards.

Alex

> -Lane
>
> --- [email protected] wrote:
>
> From: Alex Twisleton-Wykeham-Fiennes <[email protected]>
> To: [email protected]
> Subject: Re: [WebMacro-user] Optimising Variable to reduce instantiation
> overhead Date: Sun, 12 Mar 2006 21:20:22 +0000
>
> On Sun 12 March 2006 21:14, Lane Sharman wrote:
> > alex,
> >
> > thanks for this improvement and catch. Are there any issues or concerns
> > you have with this proposed update?
>
> none that I can see - there is a very slight performance hit checking to
> see whether or not _vname has been initialised inside getVariableName()
> (along with the synchronized lock acquisition), but this is only ever
> invoked while constructing a PropertyException which has such a huge
> overhead from building the stack trace that it is irrelevant.
>
> The only potential problem is that there are some 3rd party extensions of
> Variable that aren't included in the standard ant build which might break
> by making _vname private, but these are easily refactored to use the method
> call instead.
>
> Alex
>
> ps I posted some patches to the list to make Broker shutdown cleanly and
> ensure that webmacro applications unload cleanly when reloading under
> tomcat. I was about 20k over the list limit, and am in a blocking queue. 
> Do you know who is the list admin to let this through, or should I repost
> with the fixes chopped into smaller amounts?
>
> > Lane
> >
> > --- [email protected] wrote:
> >
> > From: Alex Twisleton-Wykeham-Fiennes <[email protected]>
> > To: [email protected]
> > Subject: [WebMacro-user] Optimising Variable to reduce instantiation
> > overhead Date: Sun, 12 Mar 2006 18:50:17 +0000
> >
> > All,
> >
> > more performance tweaks, this one to the org.webmacro.engine.Variable
> > class.
> >
> > performance sampling showed a large proportion of CPU time being
> > allocated to the makeName(Object[] names) class that is invoked in the
> > constructor to create the human-readable version of the Object[] that
> > stores the names, which is then stored in _vname.
> >
> > However, _vname is only ever used in situations when you generating
> > PropertyException Objects to provide sensible error messages, and for all
> > "correctly functioning" instances, this is completely redundant.
> >
> > What I've done is:-
> >
> > - disabled the call to makeName(names) in the constructor
> > - made the getVariableName() method check to see if _vname has been
> > initialised, and if not then build the name before returning it.  This is
> > now synchronized as it changes the state of the object.
> > - made all previous references to _vname in the Variable class invoke
> > getVariableName() rather than accessing the variable directly.
> > - made _vname private rather than protected thereby forcing sub-classes
> > to access it via getVariableName()
> >
> > The resulting class (attached) passes all the unit tests and completely
> > removes this overhead for all normal usage patterns.
> >
> > Alex
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language that extends applications into web and mobile media. Attend the
> > live webcast and join the prime developer group breaking into this new
> > coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > Webmacro-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/webmacro-user
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Webmacro-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/webmacro-user
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Webmacro-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/webmacro-user


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642