Increase profile saver minimum save period to 40 seconds
We save much more data with the addition of inline caches. Balance
amount of data with save period: save more but less often.
This relies on the assumptions that the number of apps being killed
in less than 40 seconds is actually small.
The 40 seconds number is pulled mostly out of thin air. Some
experiments show that we don't necessarily lose data when increasing
the period. I only looked at file sizes and the number of profile writes
to verify that we get a comparable amount of information between 20 and
40 seconds. (I did not do a delta on the profile content).
The test scenario was:
- clear all profiles
- boot the device and let it settle for 2 minutes
- open maps and navigate to a destination, search for restaurants
- open gmail and send an email
- open playstore and inspect the top charts
- open youtube and play a video
- open docs and write in a document
- all app interaction are kept below 40 seconds
- wait 1 minute to settle any pending saves
- take a bug report and look at profile stats
With 20 seconds: 43 profile writes, summing 1605610 bytes.
With 40 seconds: 35 profile writes, summing 1243217 bytes.
There is the obvious trade-off that apps being killed in less than
40 seconds will not get profiles.
Bug: 36281963
Test: m test-art-host
manual device tests to verify the profile gets saved
Change-Id: Iea2e6519c3d23b3d30bdddbbabe7e5cfd1f535ce
diff --git a/runtime/jit/profile_saver_options.h b/runtime/jit/profile_saver_options.h
index c8d256f..07aeb66 100644
--- a/runtime/jit/profile_saver_options.h
+++ b/runtime/jit/profile_saver_options.h
@@ -20,7 +20,7 @@
struct ProfileSaverOptions {
public:
- static constexpr uint32_t kMinSavePeriodMs = 20 * 1000; // 20 seconds
+ static constexpr uint32_t kMinSavePeriodMs = 40 * 1000; // 40 seconds
static constexpr uint32_t kSaveResolvedClassesDelayMs = 5 * 1000; // 5 seconds
// Minimum number of JIT samples during launch to include a method into the profile.
static constexpr uint32_t kStartupMethodSamples = 1;
