devtools: loading a heap snapshot takes too long |
||||
Issue descriptionChrome Version : 51.0.2704.106 OS Version: ubuntu 14.04 What steps will reproduce the problem? 1. go to google.com/maps 2. open devtools 3. take a heap snapshot What is the expected result? the snapshot is quickly captured / loaded What happens instead of that? It takes a very long time. Most of the time (~10s) is spent in the "Building dominator tree..." step. This quickly becomes a real bummer if you're capturing lots of snapshots. Please provide any additional information below. Attach a screenshot if possible. I feel like this used to be much faster. I profiled the capture and it's spending all the time in the "while (changed)" loop in _buildDominatorTree. It goes through several thousand iterations of that loop with only a few entries in the "affected" array set to 1, so it's spending all the time scanning several hundred thousand entries to find those few. I applied a small hack to my local chromium to add a smaller "affected2" array where each entry is the "|" of 256 entries from "affected". In this way 256 entries can be skipped at once (in the common case of mostly 0s in "affected"). This reduces the time to calculate dominators in my case from ~10s to ~200ms. UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
,
Jul 21 2016
Able to reproduce this on the latest canary(54.0.2803.0) and the latest stable(52.0.2743.82) on Windows-7, Mac OS 10.11.5 and Linux Ubuntu 14.04. This is a regression issue broken in M-50. Last good build: 50.0.2656.0 First bad build: 50.0.2657.0 Changelog: https://chromium.googlesource.com/chromium/src/+log/2e75f8e36c3f571a8946d3abba5f1919316e5d6c..b0796a63f03340dd7dacdb59cf6316d55379d8f6 V8 roll in the above changelog: https://chromium.googlesource.com/v8/v8/+log/59fb4f5b..a91392f8 Suspected change from the above Changelog: https://codereview.chromium.org/1718173002 primiano@: Could you please take a look at this and confirm if the above change is related.
,
Jul 21 2016
My CL has nothing to do with devtools. If the range is real I suspect this has more to do with the V8 roll, specifically with https://codereview.chromium.org/1719903002 which changed heap-snapshot-generator.cc. assigning to ulan to help triaging.
,
Jul 21 2016
Added to my queue, will take a look on Monday. ajha@, what is the time difference between bad and good revisions?
,
Jul 22 2016
Tested on Windows-7. On good build(50.0.2656.0) took around 4s to capture the snapshot. On bad build(50.0.2657.0) took around 48s to capture the snapshot. Around 40s was spent during "Building dominator tree..." step.
,
Jul 27 2016
Fix in review: https://codereview.chromium.org/2189643004/
,
Aug 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/ea45a210a62d24cdb6b17d6374ed7648691fa6c3 commit ea45a210a62d24cdb6b17d6374ed7648691fa6c3 Author: ulan <ulan@chromium.org> Date: Mon Aug 01 13:30:54 2016 Fix performance regression of heap snapshot generator that was introduced in https://crrev.com/72f884a19fa4434bba6fc0e013ec4ea0a2366893 The regression comes from adding the next weak field of AllocationSite as a hidden reference into the snapshot. Before 72f884 the reference was implicitly ignored because the body descriptor of AllocationSite did not include it. This patch explicitly skip the next weak field of AllocationSite. BUG= chromium:630027 Review-Url: https://codereview.chromium.org/2189643004 Cr-Commit-Position: refs/heads/master@{#38211} [modify] https://crrev.com/ea45a210a62d24cdb6b17d6374ed7648691fa6c3/src/profiler/heap-snapshot-generator.cc [modify] https://crrev.com/ea45a210a62d24cdb6b17d6374ed7648691fa6c3/src/profiler/heap-snapshot-generator.h [modify] https://crrev.com/ea45a210a62d24cdb6b17d6374ed7648691fa6c3/test/cctest/test-heap-profiler.cc
,
Aug 5 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by sheriffbot@chromium.org
, Jul 21 2016