Re: Optimising Variable to reduce instantiation overhead

Hi again!

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

I must admit that I might have gotten stuck in a wrong argument-line. It 
is probably rather the full architecture that I'm annoyed with, where the 
synchronization-issues I'm raising is rather a symptom of an underlying 
problem (as I percieve it), rather than the problem in itself.

A question one could raise in this line of argument is rather _why_ is 
there so much hitting at the concurrentmap? Not necessarily _how to 
improve the speed_, is my point, although this is obviously also a good 
thing to evaluate.

I will try to do some code at some point. But if there isn't a drive in 
the community to do this "disentagle" of concerns in WebMacro, we aren't 
really aligned.

PS: I value the stuff you're doing. It is obviously a good effort, 
cleaning up some heavy mess that's left behind after last refactor.

PPS: re equals'n'hashCode: how does things end up in the map(s)? Are they 
hitting "linear storage" where one in effect ends up with a linked list, 
rather than a hashmap? This has been the issue in some of my code, where 
hashCode had a very bad distribution, and that _really_ made for slow 
accesses. Using JProfiler (my tool of choice at the moment), this was 
rather easy to find, as one may "graph-walk" the heap, and this showed 
that some elements had a _really_ long way to their GC-roots, running 
through a huge line of HashMap.Entry elements' "next" pointers.

Kind regards,
Endre.


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