Looks like we're using the editor text settings but I think the workbench font would be more appropriate?

vs devtools:

Hi there 👋!

It looks like the release for version 1.0.4 is missing in GitHub Releases, although there is a tag for it (https://github.com/microsoft/vscode-js-profile-visualizer/releases/tag/v1.0.4). Maybe this is intentional, but wanted to bring this to your attention 😊.

This would prevent the flash when switching between tabs, at the cost of RAM while the tab is open

At first it may appears to end users that the .cpuprofile format consumed by the extension may be the one documented here:
https://gperftools.github.io/gperftools/cpuprofile-fileformat.html

That would mean that it can be used to visualise profiles of native (non-js) applications generated with gperftools.

However, digging reveals details in the closed issue #1 revealing that the actual format used is:
https://chromedevtools.github.io/devtools-protocol/tot/Profiler/#type-Profile

It would be good to make this information more visible, by mentioning it in the extension description and / or repository's readme files.

It might also be useful to provide a link to documentation of the format that is used. It seems clear that there is going to be an appetite to use this extension for visualising profiles from other sources, and knowing the correct target format is the enabling piece of information for doing that.

A guide to any applicable conversion tools, or roadmap for supporting other input formats would probably be welcomed as well.

I tend to use this in devtools more than bottom up

Doesn't feel nice since clicking expands/collapses

Hey, cool project!! When u start a node application written in Javascript it starts ok, but when u restart using the restart button, the graph goes away, so u have to stop and restart the app.

Is possible to fix this?

Thanks

Hello,

The realtime graph is not showing while starting debugging.

I can however profile a session (and I can open the .cpuprofile files generated)

nb1: Clicking on both debug sessions does not do anything.
nb2: I couldnt find anything suspect in extension logs (I could seach more if you tell me what to search for)
nb3: Here is the debug config I'm running:

{
      "type": "node",
      "request": "launch",
      "name": "Webpack debug",
      "cwd": "${workspaceFolder}",
      "args": [
        "${workspaceFolder}/output/app-entry.js"
      ],
      "protocol": "inspector",
      "outputCapture": "std",
      "sourceMaps": true,
      "env": {
        "NODE_ENV": "development",
        "TZ": "utc",
      },
      "resolveSourceMapLocations": [
             ...
      ],
      "skipFiles": [
        "<node_internals>/**/*.js",
          .....
      ]
    }

[EDIT] Oh, if it's of any help, I'm running vscode on WSL2

Current

Proposed

Currently assigning people is show as it will give a dropdown with everybody

VSCode successfully auto-attaches to processes like ts-node-dev when entered in the terminal. But when I try to display the performance graphs, none is shown. I guess maybe only one additional event handler is missing.

See the vscode-js-profile-flame header and the "package" instead of "extension" for example

Currently, timings/number of ticks are displayed as code lenses:

Imho, this is slightly annoying because a) it moves your code around and b) it's hard to get a quick overview over which line in your code is expensive to execute.
I'd like to propose an alternative display mode that instead changes the line background color up to a width proportional to the amount of time spent on that line relative to the current frame's total time (Juno has that feature):

Ignore the drastically different results for now, I think our Julia -> .cpuprofile translation has a bug somewhere.

This is possible with the current decoration API, but might require padding the end of the line with spaces.

The 0, 1, 2… make this feel like it's not a callstack

It should instead look something like the other call stacks in the product:

The description for the extension at https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-js-profile-flame is kind of confusing for end users :)

We plan to ship a new Julia extension version soon that will write .cpuprofile files. At that point the shipping version of VS Code handles those file types, and if a user clicks on the flame graph icon in the custom editor that opens the extension page that has this incomplete description.

Could you maybe publish a new version of the extension that just has a more meaningful homepage on the marketplace? Doesn't have to be long, just some text a la "This adds flamegraph support for .cpuprofile" files would be fantastic already.

[ms-vscode.vscode-js-profile-flame]: Menu item references a command extension.pwa-node-debug.startProfile which is not defined in the 'commands' section.

I can filter, but I want to focus such that the focused function makes up 100% of the measurement

I clicked this assuming it was going to open the file for me and fail if it couldn't fine it. Instead of moves the selected block which is disorienting. Is there some icon or something we could use to hint that it changes the selected block?

It seems that the profiler does not include timings for async functions: the execution time is simply attributed to the caller of the async function. This is different from what the [ms-vscode.js-debug 1.47.3] debugger does, where I can see the async methods in the call stack (after the "async function" break).

Suggestion: Can we have the profiler report the async methods as the debugger does? As it stands, it's hard to profile async code.

[I'm developing in TypeScript 3.9.6]

Version: 1.47.1 (user setup)
Commit: 485c41f9460bdb830c4da12c102daff275415b53
Date: 2020-07-13T22:42:53.386Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363

It's possible to hit these debugger statements while debugging some other extension, so you might want to remove them or compile them out for publishing.

Edge does this on shift+drag

👋 Hi there, Martin here, from the VS Code team.

Recently we've announced the Remote Repository feature that lets you browse and edit files and folders directly on GitHub.

Open Remote Repository... opens VSCode on a folder or workspace located on a virtual file system. We call this a virtual workspace. We observed that not all extension support this well, either because they can not, or they haven't thought about it.

It would be fantastic if you could test whether your extension can handle virtual workspaces:

Check out the Virtual Workspaces Extension Author Guide on how to do that.

When done, set the new virtualWorkspaces capability in your 'package.json'.

{
  "capabilities": {
    "virtualWorkspaces": true | false
  }
}

• Use "virtualWorkspaces": true if your extension is prepared for virtual workspaces
• Use "virtualWorkspaces": false if your extension should be disabled when a virtual workspace is opened

For questions and comments please use the Virtual Workspaces Tracking Issue.

Thanks for the support and the great work! ❤️

Hey 👋 We've recently been using this vscode extension to capture and investigate performance profiles while working on Next.js, this is mostly focused on CPU profiling. Today I was having a look at some memory leak reports and realized memory usage was growing uncontrollably up to 1GB in the debugger chart while the Chrome devtools debugger kept saying only 54MB was allocated.

When looking at process.memoryUsage() I realized that the extension reports the process.memoryUsage().rss instead of process.memoryUsage().heapUsed which Chrome reports. Below the chart it is labeled as "Heap used" though.

My main question is if this is a mistake or intentional? Happy to send a PR to update the label or measurement.

(just for my own future reference) In looking at the issue I found this article that goes in-depth on the differences between the metrics reported https://www.dynatrace.com/news/blog/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/

It does go to sub ms sometimes but I don't understand when it does and doesn't

Looking at the table view for a typical Julia session:

It looks to me that if I expand say the second row, then I get a list of stack frames that are calling the function on the second line, and then if I expand further I get the callers of those lines etc.

I think that is very useful, but wouldn't it be even more useful if expand showed the functions that are being called from that function, i.e. a way to drill down and see how the time is composed across the work that is being done inside the function that I'm drilling down into?

Maybe in an ideal way one could explore in both directions from any given row?

CC @pfitzseb, @aviatesk, @vchuravy

Using VSCode 1.61 x64 (fresh installation) on win11.

I tried -unintentionally, to be frank- the palette command Clear Profile Code Lenses while having opened a .js file (or an irrelevant one, e.g. .html) and in both cases I get an error: "command 'extension.jsProfileVisualizer.table.clearCodeLenses' not found":

I often need to go to it to figure out what it is. It's a problem in devtools too.

This just tells me what file some function is in, since we also own JS/TS and we know where the file goes, could we for example say something like this:

• (anonymous) requestAnimationFrame
• () => void requestAnimationFrame

Where requestAnimationFrame is the function the callback is passed into?

Or allow some way to peek at the line?

Not sure why it's so red, could we do some more color coding? It's not clear what the different shades of red. I would expect (anonymous) to have its own color for example as it's kind of in its own special category.

Can we align with Chrome or Edge?

Would it be possible to add support for Firefox launch type in Flame real-time graph to be able to monitor DOM node count, restyles per second, and relayouts per second, just like with Chrome launch type?

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

Your extension is incredibly popular with VS Code users! We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

Workspace Trust will remain disabled for the month of May, but we are planning on enabling this by default in the future. To prepare for that day, we would love for you to try it out and provide feedback.

We'd love your feedback

Since this issue was created in an automated fashion, we won't be monitoring the responses in this issue (our notifications would explode!). Instead we ask you to drop questions, and feedback in issue #120251 as we've mentioned above.

We're excited to see what you do with workspace trust!

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

Your extension is incredibly popular with VS Code users! We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

Workspace Trust will remain disabled for the month of May, but we are planning on enabling this by default in the future. To prepare for that day, we would love for you to try it out and provide feedback.

We'd love your feedback

Since this issue was created in an automated fashion, we won't be monitoring the responses in this issue (our notifications would explode!). Instead we ask you to drop questions, and feedback in issue #120251 as we've mentioned above.

We're excited to see what you do with workspace trust!

CPU usage is shown 100% even when,

• Nodejs single-threaded app is using only one core fully.
• Nodejs threaded app is using any number cores fully.
• there are clear ups and down shown on the graph.

Attaching 2 screenshots showing different cases,

1. Main nodejs app with 1 extra worker thread doing CPU intensive work.
   See, at OS level node is registering 20% CPU load. (which is close to fully utilizing one core of a quad core CPU)

2. Main nodejs app with 7 extra worker threads doing CPU intensive work.
   At OS, level node is registering 89% CPU load.

In both cases, CPU usage is shown 100%. Secondly, the graph itself has ups and downs which is not reflected in the CPU usage number.

Also is it possible to get total RAM usage? In the second screenshot, heap is 125 MB whereas at system level, node is occupying 9.5 GBs of RAM.

Should the gesture be double click or alt click instead? Devtools goes to the file on click.

Proposal:

• Click: focus the item, show the description on the bottom
• Ctrl+click: go to the file
• Double click: expand item to width

The function names are much more important here:

It could do with some padding at the top:

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".

Can I use this angular or react project or it's just use for vanila javascript project.
Thank you for great tool.

It seems to me that there is some assumption about consecutive values for ProfileNode.id built into the extension? Could that be relaxed, so that arbitrary numbers can be used there, i.e. numbers that are not counting from 1? If so, we could use the internal ids from Julia, which are all over the place, without another conversion step.

Not the end of the world, but it seems the spec is not formulating a requirement on what these ids should be, other than numbers.

This is more a question: are there plans to include the flamegraph stuff inside the core VS Code product, without the need for an extension installation? I think that would be nice.

This is pretty annoying, especially for left click. I often scroll a small amount and it's registered as a click, not a drag

I couldn't figure out how to do it otherwise, even saving a css or tsx file in vscode-js-profile-table didn't see to apply

It wasn't immediately obvious how query works

The background partially filled is a bit confusing and doesn't get to the level that I need it

vs

Not discoverable in extension search:

One of Juno's great features was that it gathered profiling, @code_warntype and @allocated in one place. It made it really easy to see, not only which parts of the code took the longest time, but also which parts probably was easy to improve.

It would be nice to have in VSCode as well