Yeah, concurrentHashMaps are REALLY slow and they hog memory. The only
time they should generally be used is if you have small, extreemly
dynamic sets of data that need to be added from multiple threads. If
there is a fixed set of data that has to be loaded at initialization
time, it's better to perform static locking on a boolean and, *maybe*
take advantage of multiple synchronization calls on startup.
Concurrent HashMaps are invaluable for threads where massive amounts of
synchronization are necessary, but they do not make sense for general
map use.
Scott
Andrew Robinson wrote:
I have been looking into this and thinking more about it since I wrote
the email. On JDK 1.6:
HashMap.get ~ 1.5 ns
ConcurrentHashMap.get ~ 5.5 ns
Now taking for example this skin hierarchy:
A > B > C > simple
Then a property lookup could result in at least 4 map get calls.
I was thinking of doing a property lookup for every styleClass encode.
So it would take 62,500 styleClasses being encoded on one page to
equal 1ms slow down. Math:
1,000,000 ns in 1 ms
1,000,000 / 4 = 250,000 is the number of possible lookups per style class
250,000 / 4 = 62,500 is the number of calls of a 4ns difference
between the two get calls
So maybe on a big page there maybe around 5000 classes written? That
would equal 80,000 ns or 0.08 ms slower. So it would take 12.5
encodings of the page to get a 1 ms difference. I guess that is pretty
much insignificant :)
Guess this thread is pointless.
-Andrew
On Tue, Apr 29, 2008 at 9:16 AM, Andy Schwartz
<[EMAIL PROTECTED]> wrote:
Hey Andrew -
On Mon, Apr 28, 2008 at 6:45 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
> What do you think, would
> it be worth investigating to improve property lookup performance?
Do skin property lookups show up as a bottleneck (or a significant
factor) when profiling a typical request?
Andy
