| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Each java.security.Provider.Service has its own cache, so there is not a
lot of benefit to having another cache of the caches. In fact, this
makes adding a new provider a huge hit. This change makes adding a new
empty provider go from ~5080 microseconds to 73 microseconds.
(cherry picked from commit cc4791ad77128039c93d4c03b582d4dc397e6a02)
Bug: 21159204
Change-Id: Ib23032f8cb0def79367a321b48241b6cc94de6b0
|
|
|
|
|
|
|
| |
Also add benchmark for Class.newInstance.
Bug: 20269715
Change-Id: Icd52155ce79a978a4d869855bfdfd7735abd8187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Contains refactoring. Benchmarks below to show no appreciable
negative performance impact to formatters. We do now cache a new
type of formatter.
Benchmarks measured in microseconds on mako.
Before:
DateIntervalFormat_formatDateRange_DATE 244
DateIntervalFormat_formatDateRange_DATE_TIME 256
DateIntervalFormat_formatDateRange_TIME 208
RelativeDateTimeFormatter_getRelativeDateTimeString 207.2
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 218.2
RelativeDateTimeFormatter_getRelativeTimeSpanString 70.5
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 67.4
After:
DateIntervalFormat_formatDateRange_DATE 237
DateIntervalFormat_formatDateRange_DATE_TIME 241
DateIntervalFormat_formatDateRange_TIME 200
RelativeDateTimeFormatter_getRelativeDateTimeString 149.4
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 161.8
RelativeDateTimeFormatter_getRelativeTimeSpanString 71.7
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 69.0
Bug: 20247811
Change-Id: I51075f89ca6b1d8862335e0e5a4d67a5624edfa6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
General strategy: Switch to ICU classes for Calendar, and generally
use ICU classes earlier to avoid multiple creations.
This also incorporates some feedback from narayan@ from
https://android-review.googlesource.com/#/c/145662/
Some small optimizations applied but the goal was not to make it
much faster, just to confirm it wasn't much slower. It has sped up
some methods, and slowed down others, but not much difference in
absolute terms.
All times in microseconds measured on a mako.
Original:
RelativeDateTimeFormatter_getRelativeDateTimeString 582.4
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 603.2
RelativeDateTimeFormatter_getRelativeTimeSpanString 39.9
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 39.1
After:
RelativeDateTimeFormatter_getRelativeDateTimeString 207.2
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 218.2
RelativeDateTimeFormatter_getRelativeTimeSpanString 70.5
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 67.4
Original:
DateIntervalFormat_formatDateRange_DATE 290
DateIntervalFormat_formatDateRange_DATE_TIME 298
DateIntervalFormat_formatDateRange_TIME 276
After:
DateIntervalFormat_formatDateRange_DATE 244
DateIntervalFormat_formatDateRange_DATE_TIME 256
DateIntervalFormat_formatDateRange_TIME 208
Change-Id: If043bd55ffec37ed2735aa1593f327b38749218c
|
|
|
|
|
|
| |
Based on a discussion with the icu team.
Change-Id: I47a6b260a9348debd65282794996f7976b8bc008
|
|
|
|
|
|
|
|
|
| |
This reverts commit 3b59929cb9978453c8bc81cf7e222c40fa42ce90.
Fixes the original flaky build issues and fixes a typo caught
by the previous review.
Change-Id: Ia8a008b75dba51980b064f9689477b8698bcfa5c
|
|
|
|
|
|
| |
This reverts commit de7c1fb9684c2558743e88fbf74a61f5ed6b47b5.
Change-Id: I22be183176e27371b3ab5fd8868598968cf01584
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first approach of building icu4j against the SDK and adding that
to the boot classpath won't work out too well. Besides being a bit
of a hack, there's no way to express that relationship for hostdex
builds.
We now compile icu4j sources along with core-libart. This is the most
direct way of expressing this relationship and allows us to include
exactly what we need.
Note that we exclude the locale SPIs, transliterators and charset code
by default.
Change-Id: Idd305e77480bc681ed5b47e740dfec20d3bc7b26
|
|
|
|
|
|
|
|
|
|
| |
Strings come from con.android.markbench.Text. This change also
reworks the dependency list for benchmarks.jar to avoid hitting the
dex limit (sigh).
bug: 17185402
Change-Id: Iffd4f88b84649c86446571fea3868e98beae3175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite the DateUtils' relative time formatting APIs
(getRelativeTimeSpanString, getRelativeDateTimeString) to use ICU ones.
Two APIs that take withPreposition parameter are not changed. Because
(a) ICU doesn't provide functionality to format preposition; (b) They
are not really computing relative time but instead calling
formatDateRange() to get the absolute time/date string.
Benchmark results on aosp_hammerhead-userdebug:
before:
benchmark us linear runtime
DateUtils_getRelativeDateTimeString 127.1 ==========================
DateUtils_getRelativeDateTimeString_ABBREV 145.0 ==============================
DateUtils_getRelativeTimeSpanString 28.0 =====
DateUtils_getRelativeTimeSpanString_ABBREV 27.9 =====
now:
benchmark us linear runtime
RelativeDateTimeFormatter_getRelativeDateTimeString 119.2 ==========================
RelativeDateTimeFormatter_getRelativeDateTimeString_ABBREV 133.8 ==============================
RelativeDateTimeFormatter_getRelativeTimeSpanString 24.6 =====
RelativeDateTimeFormatter_getRelativeTimeSpanString_ABBREV 24.7 =====
Bug: 19146457
Bug: 5252772
Change-Id: Ief74608354964a17e42191d7b1a58964f3a9acfd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My original reasons for not extending it were bogus. We can safely
cast Object[] to T[] in this case.
Also tidy up the benchmark by changing buildList(.. boolean isArrayList)
to buildList(.. Class<T extends List<Integer> list.
AFTER
SortWithComparator_arrayList, arrayListLength=4} 10881.97 ns; σ=64.97 ns @ 3 trials
SortWithComparator_arrayList, arrayListLength=16} 33235.73 ns; σ=127.45 ns @ 3 trials
SortWithComparator_arrayList, arrayListLength=64} 130317.52 ns; σ=135.31 ns @ 3 trials
SortWithComparator_arrayList, arrayListLength=256} 495200.19 ns; σ=1120.86 ns @ 3 trials
SortWithComparator_arrayList, arrayListLength=1024} 1990796.02 ns; σ=19151.58 ns @ 6 trials
BEFORE
SortWithComparator_arrayList, arrayListLength=4} 40030.32 ns; σ=509.60 ns @ 10 trials
SortWithComparator_arrayList, arrayListLength=16} 122122.08 ns; σ=182.58 ns @ 3 trials
SortWithComparator_arrayList, arrayListLength=64} 457833.87 ns; σ=1311.54 ns @ 3 trials
SortWithComparator_arrayList, arrayListLength=256} 1764647.22 ns; σ=35150.74 ns @ 10 trials
SortWithComparator_arrayList, arrayListLength=1024} 7127679.90 ns; σ=122546.75 ns @ 10 trials
bug: 18821961
Change-Id: I22a18d99598dfacbdc54cf75e38dbc32ab027754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given that ArrayLists are array backed, we can sort the underlying
array in place. A similar optimisation can be applied to Vector and
CopyOnWriteArrayList but vector isn't used often enough to slow
everything else down with an instanceof check and nobody should be
daft enough to try sorting a CopyOnWriteArrayList.
Note that it's possible to apply the same optimisation to
Collections.sort(List<T>, Comparator<? super T>) but it involves a
larger refactoring to allow us to use Object[] instead of T[] and is
accompanied by a general loss of readability.
ArrayList performance improves for all array sizes :
BEFORE
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=4} 39021.26 ns; σ=206.27 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=16} 120903.59 ns; σ=1188.88 ns @ 5 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=64} 435484.98 ns; σ=19141.88 ns @ 10 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=256} 1772876.81 ns; σ=5542.74 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=1024} 7289431.83 ns; σ=110869.13 ns @ 10 trials
AFTER
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=4} 9161.79 ns; σ=90.04 ns @ 6 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=16} 29988.90 ns; σ=74.05 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=64} 118142.86 ns; σ=1133.52 ns @ 7 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=256} 456091.11 ns; σ=9110.18 ns @ 10 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_arrayList, arrayListLength=1024} 1851939.39 ns; σ=69542.41 ns @ 10 trials
For all other lists, there's no measurable difference for
most sizes. length == 4 is harder to be sure about, given the
large standard deviations and we'd expect the time spent in
instanceof to be larger relative to the rest of what's going on.
BEFORE
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=4} 49002.02 ns; σ=1392.58 ns @ 10 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=16} 154967.88 ns; σ=332.29 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=64} 588207.14 ns; σ=1863.60 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=256} 2292967.79 ns; σ=4578.14 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=1024} 9299582.60 ns; σ=179459.24 ns @ 10 trials
AFTER
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=4} 49324.98 ns; σ=240.86 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=16} 155639.91 ns; σ=215.12 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=64} 581950.81 ns; σ=938.11 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=256} 2285933.64 ns; σ=13265.42 ns @ 3 trials
Scenario{vm=app_process, trial=0, benchmark=Sort_vector, arrayListLength=1024} 8981475.84 ns; σ=431676.48 ns @ 10 trials
bug: 18821961
Change-Id: I30a3eaf89ff478663f555c93556167107da10873
|
|
|
|
|
|
|
|
|
|
|
| |
The R.java file in this change is adapted from an autogenerated
frameworks class with android.* references stripped.
bug: 18211592
(cherry picked from commit f9362eeb6a8ec6411729a688d8050efffe8baa9d)
Change-Id: Ie627dd15e776425a1a7c0109bcf833872db46198
|
|
|
|
|
|
|
|
|
|
|
| |
These commits were equivalent but not exactly the same:
AOSP commit: adb19b9b603ba83ba49b1a10b6301e396132bf3b
Internal commit: 18e74061b760389a94439f4b14acb376809a44ce
This commit makes the internal files the same as AOSP
to make future diffs easier.
Change-Id: Ie2dcdd3940244c6dd18334b58037d2e8cca93920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
croot
cd libcore
repo start dalvik-is-dead-long-live-dalvik .
repo sync -c .
git rm -r libdvm
git add JavaLibrary.mk (after removing libdvm references, adding explict core-libart references)
git add Docs.mk (after replacing references to libdvm with libart)
git add benchmarks/Android.mk (after adding explict core-libart references)
git add Android.mk (after removing dalvik-host target)
git commit -a -m 'Dalvik is dead, long live Dalvik!'
Bug: 14298175
Change-Id: I977e7b4be8ef1043b70ceb8532ac4947ea1b7ab8
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to
https://android-review.googlesource.com/101914
Bug: 11579369
(cherry picked from 3c32023358065ddbad256a9fe7c1385592746d3e)
Change-Id: I6193489a8ca9dca6ccfa8c5ffd814baab49e0f63
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ART is completely optimizing away abs() for float and double
on x86 if the result is unused. We may soon optimize it away
on ARM as well. To avoid the benchmark becoming irrelevant
modify all the math benchmarks to use the return value.
Bug: 11579369
(cherry-picked from 547edf38495b20fa3669520cd3989243d75787ee)
Change-Id: I1c2eec3bfcef9e7b5d56522ba8330603ad774eec
|
|
|
|
|
|
| |
Please do not merge.
Change-Id: Iae444b6b2840916ef9a4d0962a55a74f650bd5a5
|
|
|
|
|
|
| |
Please do not merge.
Change-Id: Ib9fbb179f981f5159c202db15235c2129b81cb5e
|
|\
| |
| |
| |
| |
| |
| | |
updated benchmarking."
* commit '42a6d80d91d8f33162b8946e6fc05e8b43833ca7':
Expanded arraycopy function to deal with more types and updated benchmarking.
|
| |\
| | |
| | |
| | | |
benchmarking."
|
| |/
|/|
| |
| |
| |
| |
| |
| | |
Runs 48% faster on average for short arrays of length 16-128, depending on the type. Defaults to
native code for longer arrays.
Bug: 7103825
Change-Id: I70ca8f4a379600917e5bc103364af0637f18e03a
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
croot
cd libcore
repo start dalvik-is-dead-long-live-dalvik .
repo sync -c .
git rm -r libdvm
git add JavaLibrary.mk (after removing libdvm references, adding explict core-libart references)
git add Docs.mk (after replacing references to libdvm with libart)
git add benchmarks/Android.mk (after adding explict core-libart references)
git add Android.mk (after removing dalvik-host target)
git commit -a -m 'Dalvik is dead, long live Dalvik! DO NOT MERGE'
Bug: 14298175
Change-Id: I0e7a3ce47e0b6e3a7b15006a6d17d103d23e8064
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ICU can't handle the new toString forms for scripts etc.
and it's also guaranteed to deal with BCP-47 tags correctly.
Most of the changes in this patch are required to keep
backwards compatibility for getDisplayCountry string etc. in
the face of the transformations toLanguageTag performs.
A few tests were changed, but for the better.
The tagalog -> filipino charlie foxtrot will be dealt with
in a follow up change.
Co-Authored-By: Narayan Kamath <narayan@google.com>
Change-Id: Ia7f26d92a0e38c4bbb1d839c0fbd8ad16a473bf5
|
|
|
|
|
|
|
| |
This matches Chrome's behavior.
Bug: 13246961
Change-Id: I1954da3116a1759cb650bffed558dced5770e3ec
|
|
|
|
|
|
|
| |
benchmarks depend on core-tests, so won't build if
this flag is set.
Change-Id: Ia619bb9d4c30249307c0657e2d5a37ba7f259a58
|
|
|
|
|
|
|
| |
This increases speed of CipherInputStreamBenchmark from 606ms to 28.5ms.
Bug: 12246774
Change-Id: If61c0a055fe1b8e87909711b15d0441fcdbe46c7
|
|
|
|
| |
Change-Id: I3c939e9275ba8f1d00342d1f83c6fdaf110f2317
|
|\
| |
| |
| |
| | |
* commit 'eaa0add6aaa503221a530d346a3b4a066bc46449':
Minor cleanup of deepHashCode / deepEquals.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These methods used equals() comparisons where identity
checks would've sufficient. As expected, this results in a
small but measurable performance increase on both art
& dalvik.
---------------------- After --------------
ART:
arrayLength benchmark us linear runtime
1 DeepHashCode 8.08 =
1 Equals 17.68 =
4 DeepHashCode 8.63 =
4 Equals 18.20 =
16 DeepHashCode 19.59 =
16 Equals 41.19 =
256 DeepHashCode 255.41 =
256 Equals 483.61 ==
2048 DeepHashCode 2321.91 ==============
2048 Equals 4932.40 ==============================
Dalvik:
arrayLength benchmark us linear runtime
1 DeepHashCode 32.7 =
1 Equals 65.3 =
4 DeepHashCode 34.4 =
4 Equals 67.7 =
16 DeepHashCode 76.0 =
16 Equals 142.8 =
256 DeepHashCode 755.6 =
256 Equals 1515.6 ===
2048 DeepHashCode 6915.4 ===============
2048 Equals 13786.6 ==============================
------------------------ Before --------------------
Art:
arrayLength benchmark us linear runtime
1 DeepHashCode 8.13 =
1 Equals 17.86 =
4 DeepHashCode 8.63 =
4 Equals 18.92 =
16 DeepHashCode 19.59 =
16 Equals 40.89 =
256 DeepHashCode 253.88 =
256 Equals 477.02 ==
2048 DeepHashCode 2795.26 ================
2048 Equals 4962.11 ==============================
Dalvik:
arrayLength benchmark us linear runtime
1 DeepHashCode 32.8 =
1 Equals 66.7 =
4 DeepHashCode 34.4 =
4 Equals 70.1 =
16 DeepHashCode 74.1 =
16 Equals 147.9 =
256 DeepHashCode 805.0 =
256 Equals 1573.2 ===
2048 DeepHashCode 7253.4 ===============
2048 Equals 14349.8 ==============================
bug: 9320068
Change-Id: Id73bf38dd0777b2ec9004a2941523d082bbc74c9
|
|\ \
| |/
| |
| |
| | |
* commit '7e528a4abc3001c269142c4e3b8e17427d932ba0':
Improve URI.equals performance.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The main improvement is that we're vastly reducing
the amount of garbage this method creates.
Also, get rid of some incorrect checks and add a new
benchmark test case.
Before vs. After:
URI Equals 1540.1 =
URI EqualsWithHeavilyEscapedComponent 11921397.1 ==============================
URI Equals 1337.2 =
URI EqualsWithHeavilyEscapedComponent 588934.3 ==============================
Change-Id: I9ddb87b8267f0ac6a3ac85c2989cc0dd305ef6a1
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Based on measurements, copy char by char for arrays of length <= 64.
- With this change, the Ritz MemAllocBench got ~25% faster on Nexus 4
and ~20% faster on host.
- This change only handles arraycopy calls in the core libraries and
char arrays with the rest future work.
Bug: 7103825
(cherry picked from commit a3eb10feba1c3479ad99ef5c5323d011a5365f4b)
Change-Id: Ic002ced3bc2f2a682cd4b8cec07ede990edd7463
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Brings the time down from 7ms to 7us for a cache hit on Nexus 4.
Bug: 11447043
Change-Id: I7cfc055c264ce49dadc72b5acdc2f2b0b339a5a1
|
|/
|
|
|
|
|
|
| |
This in preparation for removing UnsafeBytesequence.
Split into a separate change so that it's easier to
resurrect if required.
Change-Id: I24b8cd6a56a37d4efc23cfea0b59adc0f065f5a2
|
|
|
|
| |
Change-Id: Ifb05ee34f4398ad61e047d1a7ecfcea9a787b6ca
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
them.
It takes ~1ms to create a DateIntervalFormat on a z620, and around 8ms on a
current mobile device (Nexus 4). Add a small cache of recently-used formatters,
using a big lock rather than per-thread caches since this typically only
happens on the UI thread anyway, and because all the other frameworks date/time
formatting is behind a single lock too.
Bug: 10696944
Change-Id: I8ccbe0b31b722a95a08fbc5a119173b7a0f44807
|
|
|
|
|
|
| |
(cherry picked from commit 50b871d4eb3b42a8209bb4a6d54cb649f56e873f)
Change-Id: I67e7ae5de6fc3b568c34bf56706dd5146d9f2b18
|
|
|
|
|
|
| |
(cherry picked from commit ee41931d976501d0fb4516bd43919b9564558619)
Change-Id: If14d8a4be38286df1e9239add0cc7161559e7fb7
|
|\
| |
| |
| |
| | |
* commit '645c15629a8abdb9f3a6e428ccb393eacd933552':
Replace mentions of old JSSE package name
|
| |
| |
| |
| | |
Change-Id: I7c90b08ee2b43c73e02512d0c6caaec098967e93
|
|/
|
|
|
|
| |
to use the external/mockwebserver.
Change-Id: I48ec32e94f992fe570a6d729bb38971b3f211188
|
|
|
|
|
| |
Bug: 8359981
Change-Id: I01f495f84035e2cc35196c65f0002328d347c4d0
|
|
I'll remove them from code.google.com afterwards.
Change-Id: I369a301ed0e116c7971caebc607c5a86d06d4ee2
|