All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=746238

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=f4f59ba4f985e451caf3c6dbdeba1124bfe005cea1d28ecce46c87e5bacfe52b


Bot(s) for this bug's original alert(s):

android-webview-nexus5X

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8973652685176050352

=== BISECT JOB RESULTS ===
Perf regression found but unable to narrow commit range

Build failures prevented the bisect from narrowing the range further.


Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:malloc:effective_size_avg/foreground/https_m_facebook_com_rihanna
  Change       : 1.56% | 34582953.7778 -> 35111885.7143

Suspected Commit Range
  2 commits in range
  https://chromium.googlesource.com/chromium/src/+log/db5e34d75cbfe1707467d5a4a8694cf14179840c..131e21f45f5d7b04874b636c1ffa642c13944f1e


Revision             Result                   N
chromium@487012      34582954 +- 1010306      9        good
chromium@487016      34811310 +- 608611       14       good
chromium@487017      34794460 +- 848888       9        good
chromium@487018      ---                      ---      build failure
chromium@487019      35275089 +- 460964       9        bad
chromium@487020      35111886 +- 855186       14       bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8973652685176050352


For feedback, file a bug with component Speed>Bisection

cc: hidehiko just in case
assigned to dskiba

there are two commits in the range

131e21f [tracing] Optimize TracedValue::AppendAsTraceFormat(). by dskiba · 3 days ago
6da431c Migrate ArcService to BrowserContextKeyedService part 18. by Hidehiko Abe · 3 days ago

Hidehiko's second change looks only for Chrome OS. So the first change looks the culprit.

dskiba: was this expected?

I can see how it can happen: previously we built huge string and then appended it to a small string, now we're building huge string right in the small string. I.e. previously we were getting rid of unused capacity in huge string during concatenation (which is costly for huge strings), but now we're not doing that saving on time.

But, this regression only exists when using tracing, i.e. users won't see it.

I'm slowly implementing next change in this area to optimize string concatenation, which should fix this regression and also improve performance.

Thanks for the update! Should we leave this bug open to track that work, or is it tracked in another bug?

dskiba, ping on #7?

Oops, sorry. The work on optimizing JSON serialization is done in issue 747503, so we can close this one.