Re: Optimising Variable to reduce instantiation overhead

Keats & Endre

On Wed 22 March 2006 14:58, Keats Kirsch wrote:
> 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 would totally agree with that which is why I'm trying to make my changes=
=20
transparent from a functionality point of view.  I have way too much legacy=
=20
code to refactor if the API for webmacro changed.

> 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.

I totally agree with Keats on this front.  Plus, all this talk about the ev=
ils=20
of synchronization is a little bit misplaced as well.  Synchronization can =
be=20
evil for one of two reasons:-

=2D threadlocks (which are really deeply evil, but which can be easily avoi=
ded=20
by careful design of your synchronized framework)

=2D performance overhead of synchronization.

Currently the highest amount of CPU usage in my testbed when profiling the=
=20
*entire* java runtime (tomcat, JDBC, webmacro, node application server, tes=
t=20
application) aside from blocking operations such as socket reads, is=20
ConcurrentHashMap.get being invoked by SimpleCacheManager amongst others. =
=20
This is non-synchronized (except when it detects concurrent modification in=
=20
which case it re-reads with a synchronized lock, but this is *never*=20
triggering on my test case).

Therefore, if you *are* concerned about performance, then don't worry about=
=20
the synchronization at all at present.  It would be *much* better to work o=
ut=20
a way of not hitting the Map quite so heavily which will give you a way=20
better performance response than potentially destabilising your concurrent=
=20
access to the library by tweaking the synchronization model for webmacro.

The algorithm for ConcurrentHashMap is very clean and very fast and probabl=
y=20
isn't going to get much faster.  However, the algorithms that are used for=
=20
equals() and hashcode() in the objects that are used as keys in the maps, a=
nd=20
the initial sizes of the various caches are probably good places to start.

Once I've had a look at that then I'm going to try and work out whether the=
re=20
are any places in the architecture where Map lookups can be bypassed safely=
,=20
but this is a considerably more complicated issue which involves a lot more=
=20
thinking about before any changes are made.

Alex

ps: Endre:  I would be *very* happy to evaluate any actual concrete code th=
at=20
you put forward to the list towards performance increases in webmacro.

> 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
> >| 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 thre=
ad
> >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 ha=
ve
> >_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 th=
ey
> >could be shared amongst threads (as they obviously are), but the actual
> >sharing of instances should be done in an application-specific way: if y=
ou
> >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 mu=
ch
> >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.
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> 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=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> 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