Could this support other languages as well?

[davidanthoff]

It would be great if this could support other languages than JS as well, it would be great if we could use that for the Julia extension. Presumably we would just need the ability to generate *.cpuprofile files?

If this could support other languages as well, could the branding/naming of the package ideally not use "JavaScript" too much? Just as an example, the description of one of the packages right now reads as "Flame graph visualizer for profiles taken from the JavaScript debugger".

[connor4312]

It could. Right now this is still a bit of an exploration.

Soon (this month or next month) I'll be adding support for the other types of profiles that can be taken from JavaScript targets (microsoft/vscode-js-debug#435). We'll become more generic at that point, which could open the door for visualizing other types of profiles. Or you could generate .cpuprofiles yourself--the format is fairly simple, happy to answer questions if you have any.

[davidanthoff]

Yeah, I thought that we could just generate .cpuprofiles that seems the easiest option. I did google around a bit and found some info on the format, but nothing authorative. Do you have a link with a spec? Or just some good starting point to understand the details of the format?

[connor4312]

This is the definition: https://chromedevtools.github.io/devtools-protocol/tot/Profiler/#type-Profile

[davidanthoff]

Alright, I've got so far that I can export a Julia profile result as a .cpuprofile file that can be opened with the VS Code UI :) It is pretty incomplete, though, right now I'm not exporting the tree structure.

One thing that would be helpful is to understand which optional fields from the spec you need to have present for the UI to show something useful. I believe both samples and timeDeltas are needed, right?

What about hitCount and positionTicks?

Also, am I right that some of these fields essentially hold data that is kind of duplicate in the spec? I.e. couldn't something like hitCount be computed from just the data in samples?

[connor4312]

Awesome!

Sample and timeDeltas are where we build most data from. I don't look at hitCount at all, I don't think it's included in recent versions of V8. positionTicks are used for displaying line information in the code lenses, you can get a glance of what they look like in the gif I made for the upcoming release: https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/images/1_45/js-debug-profiling.gif

Unfortunately "ticks" aren't directly correlated to time so they're not as clear to users as they could be (like, a certain number of ms per line). If Julia gives you wall clock time per-line you could just say 1 tick = 1ms... or wait until I support Tracing API profiles which have real per-line time and will require me to build support for that 🙂

By the way, the table-based visualizer is now built-in on Insiders; if you run the vscode.open command on a cpuprofile, it will be displayed nicely for people on Insiders.

[davidanthoff]

Ah, super helpful!

By the way, the table-based visualizer is now built-in on Insiders

Yes, I found that, makes it a lot easier to play with this :)

Another quick question: for a given ProfileNode, should callFrame.lineNumber and callFrame.columnNumber refer to the location of the function definition itself, right? Not a specific line inside the function, right?

And then, with positionTicks, is the idea that if I have a ProfileNode, and say that node appears n times in the samples array, then this node can have a number of elements in positionTicks, and the sum of the ticks for the entire ProfileNode should equal n?

[connor4312]

or a given ProfileNode, should callFrame.lineNumber and callFrame.columnNumber refer to the location of the function definition itself, right?

Yep

with positionTicks, is the idea that if I have a ProfileNode, and say that node appears n times in the samples array, then this node can have a number of elements in positionTicks, and the sum of the ticks for the entire ProfileNode should equal n?

I'm not sure actually, though that would make sense

[vchuravy]

@connor4312 I hope you don't mind me asking more questions :) I was working on converting from Julia internal format to .cpuprofile.

We have a sampling profiler that provides backtraces/stackframes. Right now in julia-vscode/ChromeProfileFormat.jl#3 I am converting each sampled stack frame into a linear sequence. Do I need to collapse these sequence onto each other so that they form trees? Each ProfileNode corresponds to a unique instruction pointer and so it only has one child. Is a ProfileNode in the Javascript world a single function? Each positionTick a location inside said function and each child the function called at said location?

[vchuravy]

With my most recent changes (in which I tried out my comments above), I produced https://gist.github.com/vchuravy/c38cf8dd5118f7575359f648d0653e8e which breaks the viewer with a "CallStack exhausted message". But I could open it in https://www.speedscope.app/

[connor4312]

It looks like there's a cycle in the profile you posted -- call frame 15 has frame 16 as a child, and 16 has 15 as a child.

Do I need to collapse these sequence onto each other so that they form trees?

There should be a unique node per call stack which led up to it. For instance if I make a call from foo() -> bar() -> baz() and then from oof() -> bar() -> baz(), you should end up with 6 unique nodes (with 4 unique call frames). However, if I call foo() -> bar() -> baz() and baz also calls oof (foo() -> bar() -> oof()), there should be only be four different nodes since the foo() -> bar() prefix is the same.

[vchuravy]

It looks like there's a cycle in the profile you posted -- call frame 15 has frame 16 as a child, and 16 has 15 as a child.

Yeah there is recursion in the example.

Okay gotcha. What about:

foo():3 -> bar(), foo():5->bar(). E.g. calls to the same function but on different lines? Should those be different nodes?

[connor4312]

Those ones should be the same nodes.

[vchuravy]

Okay thank you for the hints! I think I implemented that correctly, but the extension fails with "Cannot read property 'selfTime' of undefined" when loading https://gist.github.com/vchuravy/cd5729b94ed6d3a18e341d891a1a4c99 https://www.speedscope.app/ does load it, albeit not rendering the children of the top-level function... Manually inspecting my file it seems fine, so I am not sure what the issue is.

[vchuravy]

After ironing out some of the kinks, I think I got it to work and an update of my VSCode got rid of the error message.

Now comparing a profile that I took from some code that runs in about ~50-60ms I noticed that VSCode seems to drop the top-most function in this case called Main.profile_test from both the table view and the flame graphs. Additionally the total time seems off. VSCode reports ~250ms whereas the code run in 50-60ms and speedscope got it right. Maybe I am emitting the wrong positionTicks? I emit one everytime I pass through that node in the graph for the line that is active.

The profile is available here (slightly different than the one in the screenshots). https://gist.github.com/vchuravy/b12d64ae069678a5ee35ff5618da3257

[connor4312]

Nice! I don't think time difference is your fault, I noticed there was different for JS profiles vesus Chrome and correcting that has been on my todo for a little while. Super cool to see it working for you!