New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chrome profile: reported time isn't the same as dev tools #176

Open
vmarchaud opened this Issue Oct 8, 2018 · 3 comments

Comments

2 participants
@vmarchaud
Contributor

vmarchaud commented Oct 8, 2018

I was working on support an older format of cpu profile when i noticed some difference between the values reported by speedscope and by devtools :

image

Both are ordered by self time but we see a lot of difference in the list. Also we don't report the idle time in speedscope, i believe we should ?

I'm willing to put some time to inspect it, just opening an issue to keep you up to date ;)

@jlfwong

This comment has been minimized.

Show comment
Hide comment
@jlfwong

jlfwong Oct 8, 2018

Owner

It's possible this is a bug in the import, or a bug elsewhere in speedscope, though it isn't a specific goal to have this information map 1:1 w/ what devtools reports.

A specific example of something speedscope does that will result in a misalignment is to consider certain function calls to be part of whatever the previous stack was. As an example, the file format places (garbage collector) as a top-level frame in the profiler, but speedscope places it on top of whatever stack immediately precedes it. We do a similar thing for the opaque (program) calls.

See e.g. #85.

I don't confidently know offhand what would be causing this misalignment though, so it may be worth investigating and understanding it. It's possible however, that we'll discover it's an intentional different interpretation of the data.

Owner

jlfwong commented Oct 8, 2018

It's possible this is a bug in the import, or a bug elsewhere in speedscope, though it isn't a specific goal to have this information map 1:1 w/ what devtools reports.

A specific example of something speedscope does that will result in a misalignment is to consider certain function calls to be part of whatever the previous stack was. As an example, the file format places (garbage collector) as a top-level frame in the profiler, but speedscope places it on top of whatever stack immediately precedes it. We do a similar thing for the opaque (program) calls.

See e.g. #85.

I don't confidently know offhand what would be causing this misalignment though, so it may be worth investigating and understanding it. It's possible however, that we'll discover it's an intentional different interpretation of the data.

@vmarchaud

This comment has been minimized.

Show comment
Hide comment
@vmarchaud

vmarchaud Oct 8, 2018

Contributor

Well the main problem for me is that if the devtools show it in this specific way, i believe its meant to be understand like this.
However we can see considerable difference between devtools and speedscope (for exemple the idiff total time, i will for sure inspect what's going on to be able to explain it

Contributor

vmarchaud commented Oct 8, 2018

Well the main problem for me is that if the devtools show it in this specific way, i believe its meant to be understand like this.
However we can see considerable difference between devtools and speedscope (for exemple the idiff total time, i will for sure inspect what's going on to be able to explain it

@vmarchaud

This comment has been minimized.

Show comment
Hide comment
@vmarchaud

vmarchaud Oct 8, 2018

Contributor

For merging some frames, i need some digging to better understand how its working. But if the thread is blocked when the GC is running, i believe speedscope should show it as a top level frame, and same for the (program) (which is apparently v8 itself)

Contributor

vmarchaud commented Oct 8, 2018

For merging some frames, i need some digging to better understand how its working. But if the thread is blocked when the GC is running, i believe speedscope should show it as a top level frame, and same for the (program) (which is apparently v8 itself)

vmarchaud added a commit to vmarchaud/speedscope that referenced this issue Oct 9, 2018

vmarchaud added a commit to vmarchaud/speedscope that referenced this issue Oct 9, 2018

vmarchaud added a commit to vmarchaud/speedscope that referenced this issue Oct 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment