Profiling support in js-debug

[connor4312]

We want to explore performance measurement APIs in js-debug. In this month, we plan to:

• Create a command that could be called by extension plugins to capture profiles

• Expose a way for users to capture and save profiles

  • Basic profiling support
  • Rich termination conditions Add termination condition for profiling #415
  • Paused and breakpoint state while profiling Tell vscode that the debugger has continued, and unverify breakpoints, while profiles run #416
  • 💪 Support for capturing heap and tracing-API-based profiles Support for capturing heap and tracing-API-based profiles #435
  • Open profiles in untitled editors on complete Open profiles in untitled editors on complete #432

• Investigation into visualization options for the profiles (tracked in April visualization work #434)

• Add an option to start the profiling before the program launches Add an option to start the profiling before the program launches #467

[connor4312]

Work will continue in April

[jasonwilliams]

Im using 2020.5.1117 and the option doesn't come up for me in the callstack (VSCode stable not insiders) should i be seeing it?

I was reading this https://code.visualstudio.com/updates/v1_45#_new-javascript-debugger and it looks like this options is available.

the Debug: Take Performance Profile doesn't show either

[connor4312]

Make sure that you have the target you want to profile selected. That reminds me that I need to file an issue for that, thanks :)

(the child, not the parent, needs to be selected -- then the ⚪ will come up)

[jasonwilliams]

My call stack looks like this

[connor4312]

It looks like you're using the old debugger. You'll want to turn on the debug.javascript.usePreview setting to swap to js-debug.

[jasonwilliams]

Oh my bad thanks.
Whats the best way of measuring the start of an app to seeing something on the screen (next.js app), it seems i can only start the recording after a break point is hit. But say i want to measure [appStart -> Breakpoint] is that possible?

Second question, i have the flame extension installed i don't know how to get the flamegraph to show up?

[connor4312]

You can get the flame graph to show up by clicking the little 🔥 icon on the right of the filter box in the normal table view, or by using the "Reopen With" command.

Startup perf is also something I need to create an issue for. The manual solution right now is to set stopOnEntry: true in your launch config and start profiling from there.

[jasonwilliams]

ok my issue was that i didn't have the table plugin installed only the flame plugin

[connor4312]

Ah, yep. The table is installed by default on insiders but requires manual installation for the moment on stable.

[jasonwilliams]

working great now, thanks!

[LmKupke]

Can you please put links to the flame plugin and table plugin that need to be installed!

[connor4312]

Table: https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-js-profile-table
Flame: https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-js-profile-flame

I need to have better readmes for them 😛

[jasonwilliams]

Initial Feedback

it's looks great, just a couple of things i've noticed while using it

Flamegraph

Scrolling direction
I have a feeling people using this feature will have come from the browser which has the same feature, so the UX should match up for those who have muscle memory of using that.

Can the scrolling direction be changed to match up with Chrome Performance tab?
In the performance tab its scroll forward to expand, in VSCode its scroll backwards to expand.

In terms of going up and down Chrome does it weird, but maybe something like shift+scroll wheel is enough to scroll vertical? (it took me a while to realise you can hold down the left mouse click to move around, which is fine, it just wasn't obvious to me at first).

Bottom of the flamegraph
When i move down to the bottom it stops, but im not sure if its covering some of the flamegraph. Is it possible to add some spacing between the bottom of the flamegraph and the footer of the editor?

It seems right now the flamegraph snaps to the bottom of the editor and this isn't ideal

Jumping between inspect files and back to flamegraph
When i click a bar in the flamegraph it takes me to the file, is there an easy way to go back to where i was without reseting the view? If you're inspecting multiple files it can be cumbersome. I don't know if its possible to retain the same zoom/coordinates while the tab is open or maybe it could be memory intensive.

Flamegraph is not respecting sourceMapPathOverrides or webRoot
Looks like the root of a lot of the files in flamegraph is set wrong. My guess is that the flamegraph isn't respecting the webRoot set in the launch profile.

What's weird is this is only happening for some files and not others. Upon inspection it seems to be getting the path from the sourcemap itself. I think you just need to prefix the webRoot in front of the relative path from the sourcemap.

Visualisation View

I don't know what sort of queries this supports, is there documentation for this anywhere?
Can i use Globs or is it something more sophisticated. I would like to filter out all files from node_modules

[connor4312]

Thank you for the feedback on this!

Can the scrolling direction be changed to match up with Chrome Performance tab?

fixed in microsoft/vscode-js-profile-visualizer@9cc3d7d

but maybe something like shift+scroll wheel is enough to scroll vertical

Shift+wheel generally scrolls horizontally, so I made that scroll horizontally and alt+wheel screen vertically

added in microsoft/vscode-js-profile-visualizer@89cb51e

When i move down to the bottom it stops, but im not sure if its covering some of the flamegraph. Is it possible to add some spacing between the bottom of the flamegraph and the footer of the editor?

added in microsoft/vscode-js-profile-visualizer@848578b

When i click a bar in the flamegraph it takes me to the file, is there an easy way to go back to where i was without reseting the view?

added in microsoft/vscode-js-profile-visualizer@d663ec2

Flamegraph is not respecting sourceMapPathOverrides or webRoot

We were looking at rootPath for Node, but not the analogous webRoot for Chrome, fixed in b6e46d6

[jasonwilliams]

That’s incredible work thanks @connor4312!

I had a question about the search bar, what does “start a query()” mean? Is there a query langauge for this? What’s a good way to filter out vendor files like node_modules from the view?

[jasonwilliams]

We were looking at rootPath for Node, but not the analogous webRoot for Chrome, fixed in b6e46d6

This one is still not working for me, on the flamegraph i get ./src/components/[componentName].tsx when i click it it takes me to the compiled index.js output rather than the tsx file itself.

I've sent you an email with a video describing the problem

Version:
2020.5.2117

[connor4312]

I had a question about the search bar, what does “start a query()” mean? Is there a query langauge for this? What’s a good way to filter out vendor files like node_modules from the view?

There's a basic query 'language' right now (small docs). However I plan to remove support for it in favor of a simpler language like the marketplace uses and/or github, for example (this will not work today) you might write react exclude:node_modules exclude:*.js. For more advanced visualizer, I plan to explore providing a notebook that allows filtering and transforming data using plain js/ts (with an assortment of helper functions).

This one is still not working for me, on the flamegraph i get ./src/components/[componentName].tsx when i click it it takes me to the compiled index.js output rather than the tsx file itself.

Thanks, I'll take a look later this week

[jasonwilliams]

If i understand correctly the query language doesn't work right now?
(When i start typing it filters straight away)

[jasonwilliams]

It looks like the search in flamegraph view is only searching the top bar, if you search for anything else not at the top (bottom of the stack) it gets filtered out.

Is this intentional?

[connor4312]

Not particularly. It will be fixed :)