| 8ee76d4d3ee58109f859964e56d5c7f3d8c566d9 |
|
14-Jan-2010 |
Elliott Hughes <enh@google.com> |
Fix Date.toString.
Date.toString was using the TimeZone id ("America/Los_Angeles") rather than
the time zone short name ("PDT" or "PST", depending on time of year). The
naive fix made things 5x slower, so I improved Resources.getDisplayTimeZone
so the fixed Date.toString is only 2x slower. This could be improved further
with a faster getDisplayTimeZone.
I hoped to replace the body of Date.toString with a call to SimpleDateFormat,
but that turns out to be 40x slower. This patch also optimizes SimpleDateFormat
to bring the gap down to 8x by using Resources.getDisplayTimeZone instead of
asking for all the strings.
(Note that these improvements refer to the hopefully common case of localized
strings for the default locale. If you have the misfortune to need strings for
other locales, the new code will be more like 600x faster. At 0.5s a call on
the fastest current hardware, I hope no-one's actually doing that.
Dalvik Explorer -- available on the Market -- needs to do it when generating
summary reports, and it is indeed ridiculously slow. It uses two
SimpleDateFormat objects per locale, so it takes 1s per locale, for about 60
locales. I've tested Dalvik Explorer with this patch, and it does fix that
pathological behavior.)
Also fix a bug I introduced in https://android-git.corp.google.com/g/36242 that
meant that our zone names String[][] contained incorrect values (accidentally
concatenating each successive value in a row), found by existing tests now we
use more of those values.
Also replace a couple of "new Integer" calls with Integer.valueOf for a modest
speedup.
Also factor out some duplication.
Bug: http://code.google.com/p/android/issues/detail?id=6013
|