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

[Alan Bateman]

The general approach looks reasonable to me (although I haven't done a 
detailed code review) and it's good that you've got a good handle on 
where the time is spent.

I think you should socialize this on the build-dev list too as the 40k 
vs. 100k may be something that folks focused on small devices might be 
interested in. It may be that the 40k vs. 100k (to gain 3ms) is a 
tradeoff that could be configured at build time.

As tzdb is no longer a JAR then I don't think it should be added to the 
JARs file but this is detail that can be discussed if you go ahead with 
this.

-Alan.


On 23/02/2013 18:51, Xueming Shen wrote:
> 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