| 45c97df89d6c9d8b5252ba9fc27c41e75c81254d |
02-Feb-2018 |
Jeff Sharkey <jsharkey@android.com> |
Move more folks to FileUtils.copy().
Also extend API to accept a "count" argument of exactly how many
bytes to copy, and return the actual number of copied bytes.
Improve docs.
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978
Change-Id: I8d255e4f97462838c02a8ecb6d2d221188c4eff0
ileUtilsBenchmark.java
|
| b18f899241231991e314c40990eb8e9f703732d4 |
01-Feb-2018 |
Jeff Sharkey <jsharkey@android.com> |
Use sendfile() and splice() to speed up copying.
There are several places across the OS where Java code is simply
copying data between two points, which requires bringing that data
out into userspace before going back into the kernel. (That's pretty
lame.) The patches for the recent Meltdown/Spectre security issues
have made this overhead even worse, so it's finally time to move this
copying directly into the kernel.
This change adds a couple new FileUtils.copy() methods which inspect
the given streams/FDs, and attempt to do as much optimization as
possible before falling back to a slower userspace-based copy.
Benchmarks are showing typical improvements of 44% for 32KB files,
50% for 32MB files, and 35% for 32MB pipes.
Plenty of tests are included, and there's a simple kill-switch that
can be used to enable/disable the feature if it starts causing any
trouble. (A future CL will enable the optimizations.)
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978
Change-Id: I52518d529da5d961610998b9f61399064d8025cd
ileUtilsBenchmark.java
|
| 71207b5a11c1aaede2ccc2380a9c55b6ff0162d3 |
28-Sep-2016 |
John Reck <jreck@google.com> |
Switch Parcel to FastNative
Also fixes ParcelBenchmark to have bounded
memory usage to avoid OOM'ing during runs
Test: refactor, no behavior change
ParcelBenchmark results from bullhead
Before:
timeReadByte 74.43ns
timeReadInt 74.49ns
timeReadLong 74.13ns
timeWriteByte 81.81ns
timeWriteInt 82.09ns
timeWriteLong 81.84ns
After:
timeReadByte 47.08ns
timeReadInt 48.38ns
timeReadLong 48.16ns
timeWriteByte 55.90ns
timeWriteInt 55.85ns
timeWriteLong 56.58ns
Change-Id: I61b823d1d2beb86e00c196abd4dce65efa8fa7f0
arcelBenchmark.java
|
| 76a6cec97f48435863b6ab360e11f5da26d7956b |
01-Dec-2015 |
Paul Duffin <paulduffin@google.com> |
Switch to the latest version of Caliper
Added an Android.mk file to core/tests/benchmarks to build the
benchmarks against caliper-api-target to ensure that they build
correctly. Changed the implementations to work with the new
version of Caliper.
Bug: 24848946
Change-Id: Ib28026816dbc5c1d54f65974f4a1abfee299c43f
arcelArrayBenchmark.java
arcelBenchmark.java
trictModeBenchmark.java
|
| a2934d5ff0b5c4098408cd583c2c259edf37c118 |
14-Jun-2013 |
Jeff Sharkey <jsharkey@android.com> |
Cache AndroidBlockGuardPolicy to avoid allocation.
Every incoming Binder call ends up triggering a BlockGuardPolicy
update, which would thrash between new AndroidBlockGuardPolicy
instances and BlockGuard.LAX_POLICY, causing GC churn.
This change avoids the extra allocations by recycling a single
AndroidBlockGuardPolicy in a ThreadLocal. Worst-case thrashing case
is now 10% faster; from 7.46us to 6.65us.
Bug: 9424568
Change-Id: I9c3b1c097a2aecc9b1f109a824cf3ea319fb3393
trictModeBenchmark.java
|
| a197e37f7fc056f9d6db3ef24b5e6db9222e7b56 |
07-Mar-2012 |
Jeff Sharkey <jsharkey@android.com> |
Caliper benchmarks for Parcel.
Bug: 6111276
Change-Id: I4b89e4c14d2dc20e71bbaed78f285e6d539a1f0f
arcelArrayBenchmark.java
arcelBenchmark.java
|