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
