[threeten-dev] Startup tuning for j.u.TimeZone/tzdb.jar migration

[Xueming Shen]

Hi,

Here is the webrev for the changes for tzdb compiler and 
s.u.c.ZoneInfoFile that
I have been working on the past couple days. Most of the changes in tzdb 
compiler
are in the webrev I sent out last time [1], but I did  not push, so I'm 
including them
here again.

http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler3

We have a startup performance regression in the j.u.TimeZone after the 
->tzdb.jar
migration, as showed below (b74 is jdk8-b74 that uses zi and the b78 is 
jdk8-b78
that uses the tzdb.jar for j.u.TimeZone) there is a 29-30 ms vs 7-8 ms 
regression
on my aged linux machine. It is measured by using the non-scientific 
test case
TestStartup.java [2]

--------------b74----------------------
getTimeZone(America/Los_Angeles)[1]=7037
getTimeZone(America/New_York)   [2]=224
getTimeZone(America/Denver)     [3]=98
getTimeZone(Europe/London)      [4]=126
getAvailableIDs()=2166
getAliasTable()=1515
TotalTZ()=59 (ms)

--------------b78----------------------
getTimeZone(America/Los_Angeles)[1]=29267
getTimeZone(America/New_York)   [2]=1322
getTimeZone(America/Denver)     [3]=1014
getTimeZone(Europe/London)      [4]=1665
getAvailableIDs()=723
getAliasTable()=47
TotalTZ()=378 (ms)


The proposed changes here are

(1) To avoid using JSR310 new classes during tzdb->zi conversion. This 
is the main
slowdown comes from. While it's "easy" and "convenient" to use the new 
JSR310
classes to do the conversion, it has the cost of looking up, loading 
those new classes
(there are lots, and they slow down the startup and generate lots 
use/throw away
objects). The assumption is that "old" apps that use j.u.TimeZone don't 
use those
threeten classes, the lookup and loadup of threeten classes will be only 
for this
tzdb->zi conversion.

(2) To lazy-initialize the zoneId->timeZone HashMap. To put 600+ entries 
into
a hashmap also slows down the startup lots, especially most of these 600 
zones
will never be used during the lifttime of the vm. We now use the 
binary-search
for the first lookup and then put the result into the hashmap for future 
lookup.

(3) Not "jar" the tzdb.dat, just put the tzdb.dat at <java_home>/lib 
directly. This
has the cost of the size (40+k vs 100k), but it speeds up about 3 ms (out of
20ms). Given we are using un-compressed jars in jdk installation for 
performance
I would assume this is something worth doing here.

Together with all these changes, now the startup on my linux is about
13-ish ms (vs the 30ms in b78 and 7ms in b74). The speed of "pure" tz
conversion (only happens once for each tz, the tz then be cached in
hashmap) is also doubled, see [2]/[3]/[4].  I would assume the chance
that the performance team will go after me for the regression has been
reduced dramatically after this change:-)

-------------this change--------------------------
getTimeZone(America/Los_Angeles)[1]=13845
getTimeZone(America/New_York)   [2]=741
getTimeZone(America/Denver)     [3]=499
getTimeZone(Europe/London)      [4]=742
getAvailableIDs()=37
getAliasTable()=174
TotalTZ()=202 (ms)


-Sherman

[1] 
http://mail.openjdk.java.net/pipermail/threeten-dev/2013-February/000828.html
[2] 
http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler3/TestStartup.java