Re: Formatting a date

| 
| > How? (And how do I reload my webapp in Tomcat?)  
| 
| Same answer for both question:  same as you always did.

It doesn't really work properly, due to the combination of third party 
libraries' use of ThreadLocals (incl. WM if I remember my testing 
correct), Tomcat's "reuse" of its Thread-pool, and this bug:
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531 

Have you tried to reload webapps with Tomcat? It "works", but you'll leak 
memory: The ClassLoader isn't reaped, and all your caches' memory that 
can't be cleaned with some WM.shutdown() will _never_ be reclaimed.

Re: your other post:

|
| The last entry is doing exactly the same cached lookup as the second 
| entry on the same cache with a synchronized lock around the HashMap.  I 
| throw this in purely to illustrate that the performance overload of 
| synchronization is not going cripple your code.

With how many threads did you test this? 1000? 100? 10? 1? And how 
"real-life" was the scenario: how many date-formattings will one 
typically do within one rendering?

This illustrates the point about synchs that I'm trying to make: synchs 
are pretty much not noticeable at all if you access them with one thread 
(but there was a difference, and it was in the bad direction, right?). 
However, _contended_ synchs are the bad stuff. A conteded synch forces a 
complete flush of your memory-caches (read the java spec on synch if you 
haven't yet). On "small systems", this isn't that big a deal, as they tend 
to a) have one CPU (thus really only one cache), and b) have coherent 
caches if they are more. On larger systems, where CPUs might be more 
independent ("NUMA"), this can be a huge overhead.

The lookup of a HashMap is very fast (given that the hashCode is good), 
and won't make for a huge block for other threads - mostly, it will be in 
and out before it is pre-empted, and thus won't block at all (but it will 
still force a mem-synch). But it might still happen (pre-empted within a 
synch), and even _one_ context-swith due to a contended sync is bad. With 
a huge bunch of threads coming in to the different synch-blocks in your 
code, things might start to stack up: if one thread comes to a 
synch-point, not being able to go directly in, it will enter a queue. At 
that point, you'll have started a line - new threads coming in will enter 
it, and the CPU will have to context-switch to get things moving.

"One more synch" is never the thing that kills your app. But _lots_ of 
small, unnecessary synchs througout your code-path will give you a bunch 
of threads hanging on the different synchs throughout your code, and might 
then force _lots_ of context-switches.

So: If your "worker thread" _could have_ been finished within one "slot" 
of CPU time, but due to some synch have to wait one or more Context 
switches, this will start to give you noticeable performance hits. And 
when this starts to hit, you will have more and more of it, potentially 
leading to "thread thrashing".

  (Synchs are thus evil even without mentioning the different caches 
laying around, eating small amounts of memory without the user of the 
library neither being able to understand what's happening w/o firing up 
his profiler/heap-dumper, nor being able to control it when he finally 
figures out that the innocent-looking little $Text tool both synchs, and 
makes a cache of his date formatting invocations.)

Your test, which was good, reveals the following, as far as I can read:

1 "created formatting" takes 0.04026 milliseconds

1 "cached formatting" takes 0.01279 milliseconds

Which is 3.14 (hah!) times faster. (That low number really surprised me!)

(.. but maybe one ought to do the entire thing 10 times (loop it), so that 
one is _sure_ that the JIT have done all its deeds, and that the first 
test won't get the JIT impact)

But really, it was bleeding fast as it was. For this 3.14 fold "increase 
in speed" for something that will happen _not that often_, you're willing 
to create a _synched permanent cache_ in the code, even with all the 
potential pitfalls and crumbling of the code-pathway that this results in.

.. and that's before you've tested with a bunch of threads instead of one.


Re: the "lets not have discussions about proposed solutions" argument: I 
won't be using WebMacro much more from June on, I believe. Then that'll be 
good riddance for WebMacro! (.. and btw, I have actually tried to give 
some small pieces of code to WM, but it apparently wasn't accepted..)

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