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

[Masayoshi Okutsu]

Hi Deven,

Here are my comments on the proposed changes.

- zoneIndexCache should be an instance field because WeakHashMap isn't 
thread-safe and the order of IDs in zoneStrings differs in each 
DateFormatSymbols.

- equals shouldn't be replaced with equalsIgnoreCase because time zone 
IDs are (supposed to be) case-sensitive.

- Utilize auto-boxing/unboxing.

Thanks,
Masayoshi

On 4/9/2012 12:10 PM, Deven You wrote:
> 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