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

[Yoshito Umaoka]

I'm wondering if caching index matched last time (per DateFormatSymbols 
instance) is sufficient, instead of keeping multiple results in a hash map.
I guess majority of use cases repeatedly refer the index of the zone 
used by SimpleDateFormat.

-Yoshito

On 4/9/2012 10:46 AM, Masayoshi Okutsu wrote:
> 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