Skip to content
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

Process explorer as a separate renderer window #41045

Closed
RMacfarlane opened this issue Jan 2, 2018 · 9 comments
Closed

Process explorer as a separate renderer window #41045

RMacfarlane opened this issue Jan 2, 2018 · 9 comments
Assignees
Labels
on-testplan plan-item VS Code - planned item for upcoming workbench-diagnostics General VS Code built-in diagnostic issues

Comments

@RMacfarlane
Copy link
Contributor

Move the vscode-process extension inside of VSCode. Like the process reporter, launch it as a separate window.

@RMacfarlane RMacfarlane self-assigned this Jan 2, 2018
@RMacfarlane RMacfarlane added the plan-item VS Code - planned item for upcoming label Jan 2, 2018
@bpasero
Copy link
Member

bpasero commented Jan 3, 2018

@RMacfarlane @kieferrm @egamma fyi I did some initial prep work (https://github.com/Microsoft/vscode/tree/ben/taskmanager) to open a window from the main process that shows a tree with process info. I still need to polish it a little bit so that it works in a full build (currently it only works when running out of sources). I think in its current state the missing work is to polish the way how processes and their CPU/memory usage are displayed but otherwise it is already functional:

flicker_chrome58

I am happy to hand this over or to code review the changes to how the information is displayed. I think we also have to decide if we want to show more information in the tree than just the cpu/memory (e.g. a way to open logs for a specific process? a way to connect a debugger?).

/cc @weinand @dbaeumer

@weinand
Copy link
Contributor

weinand commented Jan 3, 2018

I suggest to use the code from https://github.com/weinand/vscode-processes:

  • it uses a lightweight approach (not involving PowerShell) to get the CPU load and memory information on all platforms and renders it correctly.
  • it supports commands to kill, force kill, and debug child processes.

@bpasero
Copy link
Member

bpasero commented Jan 4, 2018

@weinand why are we not using this approach also for the command line? seems a bit weird to have 2 implementations in our code base for this only on Windows.

@weinand
Copy link
Contributor

weinand commented Jan 4, 2018

The (Windows-) code in VS Code is too slow for using it in a polling loop.
@RMacfarlane please consolidate this (with input from @dbaeumer).

@bpasero
Copy link
Member

bpasero commented Jan 5, 2018

I pushed changes so that the window also opens properly from a built version of VS Code.

@dbaeumer
Copy link
Member

dbaeumer commented Jan 8, 2018

The PowerShell script is not slow in general. It samples the CPU for ~5 seconds to get a more realistic picture when we capture the CPU load since Windows doesn't store any historical data.

@weinand the wmic command btw does the same with the only difference of one sampling for 1 second once which is the default for the underlying OS call. If I run the command in the command prompt it takes ~2 seconds to return.

In general I think spawning a process every 1 - 2 seconds might not be nice when it comes to battery live. We should rather have a process we spawn once that puts itself to sleep and send the information back over a pipe or stdio.

@egamma
Copy link
Member

egamma commented Jan 8, 2018

The PowerShell script is not slow in general. It samples the CPU for ~5 seconds to get a more realistic

This results in a long pause when running code --status without any progress message that something is being computed. Can we reduce the sampling duration or show a progress message, so that it is clear that something is going on when running code --status.

@dbaeumer
Copy link
Member

dbaeumer commented Jan 8, 2018

I can add a message explaining that this takes some time.

I can reduce the sample duration as well, however this might give a incorrect picture. Since we want to use this to track down problems I would not opt to lower this too much.

@dbaeumer
Copy link
Member

dbaeumer commented Jan 8, 2018

It now shows

Collecting CPU and memory information. This might take a couple of seconds.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
on-testplan plan-item VS Code - planned item for upcoming workbench-diagnostics General VS Code built-in diagnostic issues
Projects
None yet
Development

No branches or pull requests

5 participants