Re: [WebMacro-user] Optimising Variable to reduce instantiation overhead

[Alex Twisleton-Wykeham-F. <al...@fi...>]

On Sun 12 March 2006 21:20, Alex Twisleton-Wykeham-Fiennes wrote:
> 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.

I spoke to soon (sort of).

Being relatively new to ant, I didn't realise that you had to call clean 
before compile and so there were some broken subclasses of Variable that no 
longer compile due to the private _vname change.

I've refactored these classes, and attach them to this email.

The (properly) compiled tree still passes all the unit tests.

Alex

> 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
> >
> > --- al...@fi... wrote:
> >
> > From: Alex Twisleton-Wykeham-Fiennes <al...@fi...>
> > To: web...@li...
> > 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
> > Web...@li...
> > 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
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-user