VS Code - Revision history

Seide: /* Clean up when done */ Add information about "Remote.SSH: Reconnection Grace Time"

2026-04-20T16:30:33Z

Clean up when done: Add information about "Remote.SSH: Reconnection Grace Time"

← Older revision		Revision as of 16:30, 20 April 2026
Line 33:		Line 33:

	====Clean up when done====		====Clean 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 ~~VS Code Server processes on the submission node~~ you ~~were using alive, despite no longer actively being used~~.		By default, VS Code Server will keep the processes used by your session active for a few hours after you disconnect. This takes away CPU time and memory from other users who are actively trying to use the nodes. There are two ways that you can ensure that your session gets closed in a reasonable amount of time.

	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...".		=====Shortening the Remote-SSH Reconnection Grace Time=====
			You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).

			This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching "Remote-SSH: Settings".

			: [[File:VSCode-remotesshsettings.jpg\|alt=Under the Command Palette menu, "Remote-SSH: Settings" is searched.]]

			This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for "Remote.SSH: Reconnection Grace Time" and configure this to something reasonable.

			: [[File:VSCode-reconnectiongracetime.jpg\|alt=In the "Settings" dialog box, "Remote.SSH: Reconnection Grace Time" is overridden to 300 seconds.]]

			=====Manually killing a remote VS Code server=====
			You can also manually kill a remote VS Code server 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\|alt=Under the Command Palette menu, "Kill VS Code Server on Host..." is searched.]]		: [[File:VSCode-killremote1.png\|alt=Under the Command Palette menu, "Kill VS Code Server on Host..." is searched.]]

Gsmathew at 14:02, 3 April 2026

2026-04-03T14:02:19Z

← Older revision		Revision as of 14:02, 3 April 2026
Line 37:		Line 37:
	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...".		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]]		: [[File:VSCode-killremote1.png\|alt=Under the Command Palette menu, "Kill VS Code Server on Host..." is searched.]]

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

	: [[File:VSCode-killremote2.png]]		: [[File:VSCode-killremote2.png\|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]

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

	: [[File:VSCode-killremote3.png]]		: [[File:VSCode-killremote3.png\|alt=Pop-up confirming the kill command went through.]]

	The next time you connect to the same submission node, you will have a fresh VS Code session on it.		The next time you connect to the same submission node, you will have a fresh VS Code session on it.

Mbaney at 21:55, 5 March 2026

2026-03-05T21:55:13Z

← Older revision		Revision as of 21:55, 5 March 2026
Line 24:		Line 24:

	====Ripgrep====		====Ripgrep====
	VS Code comes bundled with Ripgrep as the default search program. Even if you aren't explicitly using the search functionality, VS Code will periodically run "rg --files", which will enumerate the list of files that Ripgrep would search. In workspaces with very large numbers of small files, this can result in degraded performance due to NFS overhead amplified by small file I/O. The following tips can ensure that Ripgrep does not significantly impact performance.		VS Code comes bundled with [https://github.com/BurntSushi/ripgrep Ripgrep] as the default search program. Even if you aren't explicitly using the search functionality, VS Code will periodically run "rg --files", which will enumerate the list of files that Ripgrep would search. In workspaces with very large numbers of small files, this can result in degraded performance due to NFS overhead amplified by small file I/O. The following tips can ensure that Ripgrep does not significantly impact performance.

	=====Keep data separate from code where possible=====		=====Keep data separate from code where possible=====

Seide: /* Search tuning */

2026-03-05T21:29:40Z

Search tuning

← Older revision		Revision as of 21:29, 5 March 2026
Line 23:		Line 23:
	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.		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.

	====~~Search tuning~~====		====Ripgrep====
	VS Code comes bundled with Ripgrep as the default search program. ~~Searching in~~ workspaces with very large numbers of small files can result in degraded performance due to NFS overhead amplified by small file I/O. The following tips can ensure that ~~searches do~~ not significantly impact performance.		VS Code comes bundled with Ripgrep as the default search program. Even if you aren't explicitly using the search functionality, VS Code will periodically run "rg --files", which will enumerate the list of files that Ripgrep would search. In workspaces with very large numbers of small files, this can result in degraded performance due to NFS overhead amplified by small file I/O. The following tips can ensure that Ripgrep does not significantly impact performance.

	=====Keep data separate from code where possible=====		=====Keep data separate from code where possible=====
	Make sure that datasets are kept outside of your VS Code workspace so that searches do not look through these directories. Alternatively, by default VS Code will not search files listed in a .ignore, .gitignore, or .rgignore file, so adding directories with datasets to one of these files is another option. Any directory with only binary data is a good candidate to add to this file.		Make sure that datasets are kept outside of your VS Code workspace so that searches do not look through these directories. Alternatively, by default VS Code will not search files listed in a .ignore, .gitignore, or .rgignore file, so adding directories with datasets to one of these files is another option. Any directory with only binary data is a good candidate to add to this file. If you have changed your defaults or want to tweak these exclude settings further, these settings are found under "Settings->Features->Search".

	=====Limit maximum number of threads for searches=====		=====Limit maximum number of threads for searches=====
	By default, VS Code will automatically determine the number of threads to use when ~~searching files~~. You can force a maximum number of threads under "Settings->Features->Search->Ripgrep: Max Threads".		By default, VS Code will automatically determine the number of threads to use when running Ripgrep. You can force a maximum number of threads under "Settings->Features->Search->Ripgrep: Max Threads" in order to limit the performance impact.

	====Clean up when done====		====Clean up when done====

Seide: /* Keep data separate from code where possible */

2026-03-05T20:56:09Z

Keep data separate from code where possible

← Older revision		Revision as of 20:56, 5 March 2026
Line 27:		Line 27:

	=====Keep data separate from code where possible=====		=====Keep data separate from code where possible=====
	Make sure that datasets are kept outside of your VS Code workspace so that searches do not look through these directories. Alternatively, by default VS Code will not search files listed in a .ignore or .~~gitignore~~ file, so adding directories with datasets to one of these files is another option. Any directory with only binary data is a good candidate to add to this file.		Make sure that datasets are kept outside of your VS Code workspace so that searches do not look through these directories. Alternatively, by default VS Code will not search files listed in a .ignore, .gitignore, or .rgignore file, so adding directories with datasets to one of these files is another option. Any directory with only binary data is a good candidate to add to this file.

	=====Limit maximum number of threads for searches=====		=====Limit maximum number of threads for searches=====

Seide: /* Best Practices */ Add information about searching

2026-03-05T19:50:13Z

Best Practices: Add information about searching

← Older revision		Revision as of 19:50, 5 March 2026
Line 22:		Line 22:

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

			====Search tuning====
			VS Code comes bundled with Ripgrep as the default search program. Searching in workspaces with very large numbers of small files can result in degraded performance due to NFS overhead amplified by small file I/O. The following tips can ensure that searches do not significantly impact performance.

			=====Keep data separate from code where possible=====
			Make sure that datasets are kept outside of your VS Code workspace so that searches do not look through these directories. Alternatively, by default VS Code will not search files listed in a .ignore or .gitignore file, so adding directories with datasets to one of these files is another option. Any directory with only binary data is a good candidate to add to this file.

			=====Limit maximum number of threads for searches=====
			By default, VS Code will automatically determine the number of threads to use when searching files. You can force a maximum number of threads under "Settings->Features->Search->Ripgrep: Max Threads".

	====Clean up when done====		====Clean up when done====

Mbaney at 17:27, 21 May 2025

2025-05-21T17:27:56Z

← Older revision		Revision as of 17:27, 21 May 2025
Line 12:		Line 12:

	====Use only as a code editor====		====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.		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 system-level and user processes on the submission node 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> in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer \| here]] for larger data transfers between nodes.		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> in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer \| here]] for larger data transfers between nodes.

Mbaney: /* Cluster Usage */

2024-12-03T15:36:48Z

Cluster Usage

← Older revision		Revision as of 15:36, 3 December 2024
Line 19:		Line 19:
	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.		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 [[LocalDataTransfer \| transfer]] the files that you would like to open to either~~ a ~~less-used remote machine or your~~ local ~~machine before opening them~~.		As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.

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

Mbaney at 18:31, 14 November 2024

2024-11-14T18:31:52Z

← Older revision		Revision as of 18:31, 14 November 2024
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 extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.		[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.

			There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.

	==Cluster Usage==		==Cluster Usage==

Mbaney: /* Common Issues */

2024-10-25T16:25:39Z

Common Issues

← Older revision		Revision as of 16:25, 25 October 2024
Line 41:		Line 41:
	If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.		If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.

	# Connect to one of your Nexus submission nodes via SSH '''not''' using VS Code.		# Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.
	~~#: [[SecureShell \| Remote connect to a server]]~~
	# Navigate to your home directory. <pre>cd ~</pre>		# Navigate to your home directory. <pre>cd ~</pre>
	# Check if it is full. <pre>df -h .</pre>		# Check if it is full. <pre>df -h .</pre>
	# If it is full (Avail 0), delete some files to free up at least ~100MB of space. <pre>Filesystem Size Used Avail Use% Mounted on data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes</pre>		# If it is full (Avail 0), delete some files to free up at least ~100MB of space. <pre>Filesystem Size Used Avail Use% Mounted on data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes</pre>
	# Try connecting with VS Code again.		# Try connecting with VS Code again.