Migrate Collator classes to use ICU4J.
The following benchmarks have been run and show the performance
gains from calling ICU4J.
----- ICU4J -----
benchmark us linear runtime
CollatorIdentical 6.90 ==============================
CollatorPrimary 3.20 =============
CollatorSecondary 3.79 ================
CollatorTertiary 4.28 ==================
vm: app_process
----- ICU4C -----
benchmark us linear runtime
CollatorIdentical 11.75 ==============================
CollatorPrimary 10.01 =========================
CollatorSecondary 9.88 =========================
CollatorTertiary 10.26 ==========================
vm: app_process
All tests relating to Collation pass after this change.
With respect to CJK character loading time, tests were done on a
Nexus 6 running this change, in the US locale and TRADITIONAL_CHINESE
locale.
In EN-US:
Time to load Traditional Chinese collator after boot: 76ms, 76ms
Time to load again: (39ms, 36ms, 36ms), (36ms, 36ms, 48ms)
In ZH-TW:
Time to load Traditional Chinese collator after boot: 37ms, 36ms
Time to load again: (36ms, 36ms, 36ms), (35ms, 37ms, 35ms)
This seems to indicate the system is creating a Collator on boot meaning
that ICU is caching it after the first creation. So if a device is in the
Traditional Chinese locale, the cost of creating Traditional Chinese
collators should have been absorbed at boot time.
Loading up the CJK ideographs uses up around ~500k of memory. From the
above findings, if the device is in a language requiring those characters
then they should be loaded up on boot in the Zygote, which may mean the
memory is shared across processes wishing to use the data.
Change-Id: I98a1c32c8f58e03d16d694b8a4fca4ced961af8e
14 files changed