VS Code: Difference between revisions

From UMIACS
Jump to navigation Jump to search
No edit summary
 
(17 intermediate revisions by the same user not shown)
Line 1: Line 1:
[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through use of extensions available via a [https://marketplace.visualstudio.com/vscode its marketplace].
[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.
 
==Cluster Usage==
It can be convenient when using our [[SLURM]] computing clusters to open a connection to a [https://code.visualstudio.com/docs/remote/vscode-server VS Code Server] session on the submission node(s) that you have access to via VS Code's [https://code.visualstudio.com/docs/remote/ssh Remote - SSH extension]. Steps to set this up can be found [https://code.visualstudio.com/docs/remote/ssh#_installation here].
 
===Best Practices===
Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of "best practices" that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.
 
====Use only as a code editor====
VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other processes on the submission node (both system-level and other users') slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.
 
The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as <code>mv</code>/<code>cp</code>/<code>rm</code> for local file management instead, or use the techniques advertised [[Data_Transfer | here]] for larger data transfers between nodes.
 
====Do not open large files====
Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.
 
As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Either use a lighter-weight command-line based text editor such as [https://www.vim.org/ vim] or otherwise on the submission node itself, or first [[Data_Transfer | transfer]] the files that you would like to open to either a less-used remote machine or your local machine before opening them.
 
If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.
 
====Cleaning up when done====
If you are done using VS Code for an extended period of time (several hours / overnight), consider manually killing your server session on the submission node when exiting. By default, VS Code Server will keep the processes used by your session active for a few hours after you disconnect, keeping the RAM you were using allocated despite no longer actively being used.
 
This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching "Kill VS Code Server on Host...".
 
: [[File:VSCode-killremote1.png]]
 
Select the submission node you were using and click on it.
 
: [[File:VSCode-killremote2.png]]
 
Wait a few seconds and you should get a message confirming the command went through.
 
: [[File:VSCode-killremote3.png]]

Latest revision as of 19:17, 15 May 2024

Visual Studio (VS) Code is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its marketplace. The base editor itself is free, but some extensions may require paid subscriptions.

Cluster Usage

It can be convenient when using our SLURM computing clusters to open a connection to a VS Code Server session on the submission node(s) that you have access to via VS Code's Remote - SSH extension. Steps to set this up can be found here.

Best Practices

Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of "best practices" that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.

Use only as a code editor

VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other processes on the submission node (both system-level and other users') slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.

The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as mv/cp/rm for local file management instead, or use the techniques advertised here for larger data transfers between nodes.

Do not open large files

Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.

As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Either use a lighter-weight command-line based text editor such as vim or otherwise on the submission node itself, or first transfer the files that you would like to open to either a less-used remote machine or your local machine before opening them.

If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.

Cleaning up when done

If you are done using VS Code for an extended period of time (several hours / overnight), consider manually killing your server session on the submission node when exiting. By default, VS Code Server will keep the processes used by your session active for a few hours after you disconnect, keeping the RAM you were using allocated despite no longer actively being used.

This can be done by opening the Command Palette (Ctrl+Shift+P) and searching "Kill VS Code Server on Host...".

VSCode-killremote1.png

Select the submission node you were using and click on it.

VSCode-killremote2.png

Wait a few seconds and you should get a message confirming the command went through.

VSCode-killremote3.png