<i18n dev> <i18n> Performance patch for DateFormatSymbols.getZoneIndex(String)

[Deven You]

Hi i18n-devs,

The getZoneIndex() method is expensive and it's performance depends on 
which timezone you're in. This is because the code steps through a list 
of timezones until it finds the current one. This is happening over and 
over again. An idea would be to either cache it or rewrite the way we 
store time zone ids, such as a hashmap instead of an array.
This patch[1] is for the cache option.

Applications which  format/parse dates using SimpleDateFormat repeatedly 
may obtain benefits from this patch, especially when run in a timezone 
far down the zoneStrings array the improvements will be even bigger.

I have written a test case[2] which shows when a timezone which is in 
lower end of the zone strings array, the performance improvement this 
patch can get.

test results:

no patch:
The total time is 742 ms!

with this patch[1] :
The total time is 508 ms!

If increase the loop times to 1000000, the results are:

no patch:
The total time is 4743 ms!

with this patch[1] :
The total time is 2126 ms!

The java version is:

/home/deven/hgrps/jdk8/build/linux-i586/j2sdk-image/bin/java -version
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 
1.8.0-internal-deven_2012_03_14_16_14-b00)
OpenJDK Server VM (build 24.0-b02, mixed mode)

[1] http://cr.openjdk.java.net/~youdwei/DateFormatSymbol_perf/webrev.00/ 
<http://cr.openjdk.java.net/%7Eyoudwei/DateFormatSymbol_perf/webrev.00/>
[2] GetZoneIndexTest.java
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120409/ed59e6c8/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GetZoneIndexTest.java
Type: text/x-java
Size: 2450 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120409/ed59e6c8/GetZoneIndexTest.java