diff options
author | Jeff Sharkey <jsharkey@android.com> | 2020-04-20 21:26:27 -0600 |
---|---|---|
committer | Jeff Sharkey <jsharkey@android.com> | 2020-04-21 09:38:36 -0600 |
commit | d387e79ae1cbc6b4fd16bfc315ec2fc63f6f6aca (patch) | |
tree | 275fd58ba3c81cd859400e907b793c8f534c172e /tools/aapt2/java/JavaClassGenerator_test.cpp | |
parent | 6d18727690e430d60b17a4652966b018c5931c14 (diff) |
Offer to write Strings through Parcels as UTF-8.
Recently while investigating some Binder limits, I discovered that
we're still sending Strings across Binder as UTF-16, which is very
wasteful for two reasons:
1. The majority of data flowing through APIs like PackageManager is
already limited to US-ASCII, and by sending UTF-16 we're wasting
half of our transactions on null-byte overhead.
2. Internally ART is already "compressing" simple strings by storing
them as US-ASCII instead of UTF-16, meaning every time we want to
write a simple string to Binder, we're forced to first inflate it
to UTF-16.
This change first updates Parcel.cpp to accept char* UTF-8 strings,
similar to how it accepts char16_t* for UTF-16. It then offers
both UTF-8 and UTF-16 variants to Parcel.java via JNI. We also
update the String8 handling to behave identical to String16.
This change adds benchmarking to show that these new methods are
about 50% faster for US-ASCII strings, and about 68% faster for
complex strings that reference higher Unicode planes. (So an
improvement in both cases!)
Bug: 154436100
Test: atest FrameworksCoreTests:ParcelTest
Test: make core-libart conscrypt okhttp bouncycastle vogar caliper && vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/ParcelStringBenchmark.java
Change-Id: I22a11d3497486d922ec8e14c85df66ca096b8f2a
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions