diff options
| author | Tobias Thierer <tobiast@google.com> | 2016-08-17 17:45:47 +0100 |
|---|---|---|
| committer | Tobias Thierer <tobiast@google.com> | 2016-09-01 11:00:16 +0100 |
| commit | 5e5169a394fd431609c3419bb4052e71dc73fed3 (patch) | |
| tree | 014318d2145de1fb2e3bda77f5de1ba8b5e7fae5 /include/ScopedJavaUnicodeString.h | |
| parent | 6e0b3562646d9b6f64882decf1dd3c65e70e1869 (diff) | |
Speed up needlessly slow libcore CTS tests
On a Nexus 6P,
run cts -p android.core.tests.libcore.package.libcore
currently runs for about 20 minutes. This consists of
two runs (arm32 and arm64 runtimes) that involved 587sec
each spent running the set of test methods.
This CL speeds up the test methods that ran the longest
(11-21sec per method) as measured by comparing wallclock
timestamps in a CTS run. The speedup is about 10% (59sec
faster per run, to now 528sec per run).
The speedup is achieved by Thread.sleep()ing for shorter
in tests that slept for what appeared like excessive
amounts of time, and by decreasing data sizes / loop counts
for probabilistic tests for race conditions. There was no
evidence apparent that these had found any bugs in years,
so needing to run them more often to find a potential bug
appears like a fair trade-off for a 10% speedup.
Test: run cts -p android.core.tests.libcore.package.libcore
(ran this three times)
Bug: 30948560
Change-Id: I9b28ce60268746b3a5edfc5b94dcc2ec29c8feca
Diffstat (limited to 'include/ScopedJavaUnicodeString.h')
0 files changed, 0 insertions, 0 deletions
