New issue
Advanced search Search tips

Issue 768540 link

Starred by 6 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Devtools Performance tab splits function calls into multiple.

Reported by trusktr@gmail.com, Sep 25 2017

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 9592.96.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.114 Safari/537.36
Platform: Any

Steps to reproduce the problem:
1. Visit this website: trusktr.io/polydance (on a desktop OS)
2. Record in the Performance tab for a few seconds.
3. Look in the timeline and for each animation frame notice that sometimes the `motorLoop` function is split into two or more sections.

What is the expected behavior?
The `motorLoop` function is only called once per animation frame, so I would expect to always see a single continuous bar for the `motorLoop` calls.

What went wrong?
Sometimes, the bar representing the `motorLoop` calls are split into two or more sections, giving the impression that the `motorLoop` function is being called more than once per frame, but this is not the case.

I can verify that this isn't the case because I can monkey patch `requestAnimationFrame` to log something at the beginning and end of each frame, and I can make `motorLoop` log something as well, and the console.log statement inside `motorLoop` is only ever logged once between the two outer start/end logs of the animation frame.

Did this work before? Yes Not sure.

Chrome version: 60.0.3112.114  Channel: n/a
OS Version: 9592.96.0
Flash Version: 

I've never noticed this behavior until now.

Something that I noticed is that the splitting of the `motorLoop` function's timeline bar is always during points of numerous calls to WebGL APIs. It never happens before the calls to the WebGL APIs.

You'll see a `drawScene` function which is the function that encapsulates all the WebGL calls, and the split always happens during the `drawScene` call inside of the `motorLoop` call.

`motorLoop` is the root function inside the animation frames, besides the microtask stuff which is Vue.js related.
 
Owner: caseq@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 2 by caseq@chromium.org, Oct 2 2017

Components: -Platform>DevTools Platform>DevTools>Performance
Owner: alph@chromium.org

Comment 3 Deleted

I have the same issue. While the original post here states that it can be split into two or more sections, when I encountered it my function was split into several hundred, maybe a thousand sections. This makes the Performance section essentially unusable.

I'm using AngularJS and vis.js. I'm not using WebGL.

Reproduced in v61.0.3164.100 (64-bit) and v63.0.3235.0 canary (64-bit) on Windows 10.

Attached is a screenshot.

(Sorry for double-posting, but I thought it would be good to add more details than my original comment contained)
9qV3a.png
334 KB View Download
I can report the same issue as well.  Only jQuery - no webgl nor angular.

Comment 6 by alph@chromium.org, Dec 5 2017

Can also reproduce on https://meduza.io

Screen Shot 2017-12-05 at 1.33.47 PM.png
414 KB View Download
Project Member

Comment 7 by bugdroid1@chromium.org, Dec 13 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/f514cc967dd2e0c75ac29864eb3ae47a7d167dee

commit f514cc967dd2e0c75ac29864eb3ae47a7d167dee
Author: Alexei Filippov <alph@chromium.org>
Date: Wed Dec 13 00:05:45 2017

[cpu-profiler] Introduce NativeFrame type.

The new frame type is inteneded to represent native C++ stack frames.
JS code may sometimes make calls to helper native functions that do not
provide any special stack layout besides the return address and frame pointer.

Currently the stack iterator bails out when it sees an unknown frame.
The patch allows the iterator to unwind stacks having such frames.

BUG= chromium:768540 

Change-Id: I9c273c7015695a6733c0a0c52b522fca7b25de0d
Reviewed-on: https://chromium-review.googlesource.com/794991
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50058}
[modify] https://crrev.com/f514cc967dd2e0c75ac29864eb3ae47a7d167dee/src/frames-inl.h
[modify] https://crrev.com/f514cc967dd2e0c75ac29864eb3ae47a7d167dee/src/frames.cc
[modify] https://crrev.com/f514cc967dd2e0c75ac29864eb3ae47a7d167dee/src/frames.h
[modify] https://crrev.com/f514cc967dd2e0c75ac29864eb3ae47a7d167dee/test/cctest/test-cpu-profiler.cc
[modify] https://crrev.com/f514cc967dd2e0c75ac29864eb3ae47a7d167dee/tools/v8heapconst.py

Comment 8 by alph@chromium.org, Dec 13 2017

Status: Fixed (was: Assigned)

Comment 9 by alph@chromium.org, Dec 14 2017

Cc: alph@chromium.org
 Issue 643420  has been merged into this issue.
This isn't fixed, I still see it.

Related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=798232
Oops, nevermind, I spoke too soon: I'm in Electron, which has an older version of Chrome.
I still see this problem in Chrome 67 (the yellow-boxed gaps should not be gaps)
chrome-profiler.png
251 KB View Download
When to fix?

Sign in to add a comment