Re: Optimising Variable to reduce instantiation overhead

Your opinion certainly has some merit, but what you're suggesting is a=20
complete rearchitecture of WM.  While that would probably be a good=20
thing, for now we're just looking at a few little performance tweaks.

I think initially WM was envisioned primarily as a templating framework=20
for Servlet applications, so thread-safety was a big concern.  Over time=20
it has evolved into more of a general purpose templating framework, but=20
there is still a lot of Servlet-oriented stuff embedded.  If we had=20
developer interest we could start talking about WM3 which might better=20
decouple various facets.  But for now we have a pretty handy little tool=20
that works pretty well.

Keats

Endre St=F8lsvik wrote:

>| I don't think it's the same at all.  Synchronization is a safety measu=
re with
>| a small performance penalty.  If you can't show that your code is alwa=
ys
>| thread-safe, you should synchronize.
>
>Well, we've managed to reduce this down to what it is: opinions!
>
>I _totally_ don't agree with this: (library) code should _never_ be thre=
ad=20
>safe, as a rule of thumb!!
>
>It is generally the _use_ of (library) code that should ensure thread=20
>safety, if it is necessary in the situation at hand.
>
>I find the Hashtable and Vector and StringBuffer approach of doing thing=
s=20
>"threadsafe" from the start totally utterly backwards, and happily "java=
"=20
>is going directly away from this approach (HashMap, ArrayList and=20
>StringBuilder).
>
>A library should as a rule of thumb be developed in a way that makes=20
>synchronization unnecessary and indeed _obvious_, and not include "smart=
"=20
>stuff within it that requires synchronization (typical example: internal=
=20
>smart-ass caches that are there to reduce the impact of badly written=20
>code). On this aspect, WebMacro has gotten it totally wrong: WebMacro ha=
ve=20
>_way_ to much bloat in it, due to the fact that it wasn't really decided=
=20
>until "recently" that it shouldn't be a "web framework", but rather "a=20
>macro-merging utility". However, this hasn't been brougth to the end:=20
>there are still way to much magic, hidden smarties and bloat within=20
>webmacro.
>
>The very bad examples are the following:
>  *) The concept of "the configurable broker", with way too much=20
>responsibility.
>  *) Reloading of templates, thus forking threads!!
>  *) Luckily the _downright idiotic_ "time thread" is already gone, so I=
=20
>can sleep better at night.
>
>Those things shouldn't have anything to do with the tight little=20
>macro-merging utility/library that WebMacro ought to be.
>
>I can't see one reason for why WebMacro couldn't be developed in a way=20
>that would do _all_ synchronization unnecessary (the lazy init of that=20
>dear name _might_ constitute an exception, but even there, since this is=
=20
>utterly exceptional, this could be done "every time" instead).
>  Templates should be immutable and not contain state at all, so that th=
ey=20
>could be shared amongst threads (as they obviously are), but the actual=20
>sharing of instances should be done in an application-specific way: if y=
ou=20
>didn't handle the caching (and thus synchronization) yourself (by some=20
>plugin, or whatever), you wouldn't get any, and the whole thing was=20
>totally linear and un-synchronized (make Template, make Context (or just=
 a=20
>Map?), merge()).
>
>
>Note that this isn't just a point about the syncronization per se, but a=
s=20
>an architectural idea: if things are straightforward, linear, and withou=
t=20
>hidden magic, they _tend to not need_ synchronization, and tend to be mu=
ch=20
>easier to understand and not least debug when things doesn't go your way=
.=20
>Not to mention the "safe feeling" one gets when a library is truly=20
>understood and the call-paths are obvious and linear.
>
>Kind 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