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

[Stephen Colebourne]

I don't have any particular comments here. Main thing is that it works...
Stephen


On 23 February 2013 18:51, Xueming Shen <xueming.shen at oracle.com> 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