Re: Formatting a date

On Tue 28 March 2006 10:06, Endre St=F8lsvik wrote:
> 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?

Much as I hate to rise to the occasion, I'll just attempt to put this one t=
o=20
bed.

creating: 4007
HashMap: 1295
ConcurrentHashMap: 1292

creating: 3787
HashMap: 1285
ConcurrentHashMap: 1289

creating: 3795
HashMap: 1284
ConcurrentHashMap: 1288

creating: 3787
HashMap: 1290
ConcurrentHashMap: 1287

creating: 3786
HashMap: 1287
ConcurrentHashMap: 1288

creating: 3797
HashMap: 1289
ConcurrentHashMap: 1457

creating: 4031
HashMap: 1320
ConcurrentHashMap: 1319

creating: 3882
HashMap: 1288
ConcurrentHashMap: 1305

creating: 3866
HashMap: 1308
ConcurrentHashMap: 1311

creating: 4244
HashMap: 1292
ConcurrentHashMap: 1328

This is the same as the original test, just repeated 10 times to give the j=
it=20
time to kick in.  In addition, the tests have been changed as follows:-

Creator: new SimpleDateFormat for each invocation
HashMap: using an unsynchronized HashMap for access
ConcurrentHashMap: using an unsynchronized ConcurrentHashMap for access fro=
m=20
the concurrent.jar shipped with webmacro (does anyone know what version thi=
s=20
is?)

So that deals with the JIT issues.

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

Hence the usage of ConcurrentHashMap in the updated test.  ConcurrentHashMa=
p=20
*does* sync but only if the first lookup fails to return a sensible result=
=20
(therefore implying concurrent modification and reading).  This has therefo=
re=20
moved the percentage chance of a contended sync from "two threads want to=20
look up a SimpleDateFormat in the time it takes to read from a HashMap" to=
=20
"one thread wants to look up a SimpleDateFormat from a ConcurrentHashMap=20
while another thread is storing a newly initialised SimpleDateFormat at=20
exactly the same time" which kind of is "good enough" odds to me that it=20
isn't going to cripple my application.

=46inally, if we are going to be planning on boycotting all "hidden caches"=
 of=20
code, have you actually looked at the source code for SimpleDateFormat?  On=
e=20
of the first things that it does when it boots up is to retrieve the=20
NumberFormat that it is going to use from a nice little HashMap of cached=20
NumberFormat items with Locale as the key.  So the outer Map of=20
SimpleDateFormats is evil and should be stopped, and the inner Map of=20
NumberFormats is good and we don't care about it?

The final thing to notice about SimpleDateFormat is that it really isn't a=
=20
nice thing to do to your garbage collector.  It really does generate a=20
*large* number of temporary items during the initialisation of=20
SimpleDateFormat, all of which will need garbage collecting (~40 Objects=20
taking up ~1k per init) .  Looking at the initialiser makes it pretty obvio=
us=20
that it is designed to be initialised once and then run multiple times as t=
he=20
parse() and format() methods have been designed to minimise object creation=
=20
and are quite streamlined whereas the creator is a bit of a beast.

Alex


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