Elm: changing tool from toolbar on chrome:tracing is extremely slow |
||||||
Issue descriptionChrome Version: 55.0.2883.87 Chrome OS Version: 8872.70.0 Chrome OS Platform: Elm Steps To Reproduce: (1) Open chrome:tracing (2) Load "trace_extremely-slow-keyboard-mouse-during-trace.json" (3) Active tool in chrome:tracing toolbar should be the range tool |<-->| (3) Open a new window (4) Go To chrome:tracing (in the new window) (5) Start an "Input Latency" Trace (6) Go back to first trace window (7) Click "arrow" in toolbar Expected Result: Tool changes to arrow immediately. Actual Result: Tool change takes several seconds to change to arrow immediately. Attached trace_SuperSlowTracingUI.json which was is the trace taken showing how slow the toolbar was to change. How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) At least somewhat repeatable. I tried again on a different machine on 57.0.2933.0 / 9035.0.0 with a different (much simpler) set of traces and I could not repro. The first goal of this bug is to figure out why tool selection (the InputLatency::MouseDown bar in trace_SuperSlowTracingUI) took ~3 seconds.
,
Feb 10 2017
,
Jul 14 2017
,
Aug 23 2017
dsinclair@ can you please triage?
,
Aug 23 2017
benjhayden@ you've worked on tracing more recently then me, can you triage please.
,
Aug 23 2017
Thanks! I'm happy to help here. Devtools Performance traces are actually more useful for debugging performance of a web page. I tried to repro using those traces (and I had several other heavy tabs open) while recording both a devtools and chrome:tracing trace. The mouse mode selector was plenty fast on my beefy linux desktop, so I doubt that trace viewer is doing anything crazy. This part of the code hasn't changed since well before 55, AFAICT, so I doubt it's a regression in trace viewer. I just skimmed through the click handler for the mouse-mode-selector, and it looks pretty light. https://github.com/catapult-project/catapult/blob/master/tracing/tracing/ui/base/mouse_mode_selector.html#L400 https://github.com/catapult-project/catapult/blob/master/tracing/tracing/ui/timeline_track_view.html#L199 https://github.com/catapult-project/catapult/blob/master/tracing/tracing/ui/base/timing_tool.html#L77 The cpu usage during that 3s click response is pretty low in that trace. I clicked the M (metadata) button in trace_SuperSlowTracingUI.json.gz and noticed that that device only has 3938MB total memory. Trace viewer can take up a lot of that, especially if there are two of them open in separate tabs, even if their traces are small. Unfortunately, I don't see any memory measurements in that trace. I'll ask memory-infra about recording some basic counters by default. So I'm thinking disk swap paging latency. Can you test that hypothesis by reproducing with a linux performance tool like top running? Please assign it back to me if I'm wrong and I can take another look. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by benhenry@chromium.org
, Feb 10 2017