Re: Optimising Variable to reduce instantiation overhead

Endre St=F8lsvik wrote:

>On Fri, 17 Mar 2006, Keats Kirsch wrote:
>
>I do get that _Templates_ are shared. But are all Macro-implementing=20
>objects in WebMacro shared?=20
> =20
>
A compiled (built) template has a list of Macro objects that get=20
evaluated (expanded) on each request.  These include any variables=20
(unless they've been optimized into text at build time), as well as=20
directives, and functions.  Most of the time the state for these macros=20
is stored in the context, so things are thread-safe.  Any exception=20
would require synchronization.

>I am just asking here, really.
>
>(.. maybe this then should be worked over?! The synched Map/Set/Whatever=
=20
>lookup must be hitting hard?!).
> =20
>
There is very little synchronization required, because the state is=20
generally stored in the Context.  This has been further reduced by using=20
the concurrent utilities.  If you see anything being synchronized that=20
has a real performance impact, we should look at it.

>| An alternative, if you *really* can't stand synchronization, would be =
to get
>| rid of the member variable altogether and just have the display name c=
omputed
>| every time it is requested.
>
>That is a very good idea, and way better if this is a method that wont b=
e=20
>called in the standard case.
>
>|  I don't see any performance benefit to this, but
>| it would keep the state from being modified.
>
>Immutables are the very best paradigm when it comes to multithreading, i=
f=20
>possible. IMO.
>
As a general rule, I agree.  But there are always exceptions.  In this=20
case we're talking about exceptional cases.  I think it's really 6 of=20
one, a half dozen of the other.  In either case we just need to comment=20
the code so that future developers will understand what's going on.

>| I also agree that it is a mistake to optimize exceptional cases withou=
t any
>| empirical evidence of a performance issue.  This is a classic case of =
what
>| Bruce Eckel ("Thinking in Java") calls "premature optimization".
>
>Well, the same goes for syncronization, doesn't it?
>
>Don't synch if you don't need to, kinda. And if you need to, then do you=
=20
>really?? (.. and here you don't, as you perfectly point out).
> =20
>
I don't think it's the same at all.  Synchronization is a safety measure=20
with a small performance penalty.  If you can't show that your code is=20
always thread-safe, you should synchronize.  Fortunately there are=20
various ways to reduce the impact of this; such as using Doug Lea's=20
concurrent utilities.

Keats

>Regards,
>Endre.
> =20
>




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
that extends applications into web and mobile media. Attend the live webc=
ast
and join the prime developer group breaking into this new coding territor=
y!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642