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

[Keats K. <ke...@xa...>]

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

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

Keats

Endre Stølsvik wrote:

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