microsoft / microsoft/vscode-remote-release

Better documentation about resource usage of VS Code with docker/wsl2

Open
#5,985 0 comments 0 reactions 1 assignee View on GitHub

@chrmarti is already working on this.

Since Dec 16, 2024.

containers doc feature-request
Dominant language
Dockerfile
Stars
4.2k
Forks
470
Avg merge
1d 1h
Merged PRs (30d)
1

Description

This is a request for better documentation. I'm not sure where to put it, as SO isn't the right place. I submitted it as feedback on the page https://code.visualstudio.com/remote/advancedcontainers/improve-performance but I'd also kind of like to know the answer sooner if possible. So here's what I wrote:


I'd like to see a realistic comparison of resource efficiency, between:

  1. Using VS Code in a windows folder with just Git Bash
  2. Using VS Code with a container that uses bind-mounts to a local folder
  3. Using VS Code with a project that's inside WSL2, using Remote WSL2
  4. Using VS Code with a project that's inside a new Docker container, which stores its volume/etc inside WSL2
  5. I'm not sure if I missed any realistic combination scenario here, but the point is I'd like to know all the options

In order to help me choose what to use for local dev, I'd like to see a baseline comparison of all these, and how they compare. Maybe even a bar chart. But at the very least, something that explains how all 3 compare with CPU, memory, and disk usage.

The point is: I have a mid-range work laptop, and I know it's going to only last like 5 years if I use option 1, and optino 2 sounds like it'll shorten the disk lifespan a lot (who knows how much). And if I go with options 3 or 4, how much will they shorten my poor little laptop's lifespan?

To me, these seem like essential questions to have answered, if I'm going to know how to best setup VS Code to take advantage of its features on any given laptop.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.