Reputation: 8804
I'm working on an ASP.NET application in Visual Studio 2017, and I'm noticing a "Node.js: Server-side JavaScript" process running at 1.3 GB to 1.8 GB of memory. My IIS worker process is the normal size it is in Visual Studio 2015.
My application doesn't include any Node.js libraries. I'm not able to figure out how to turn this Node.js: Server-side JavaScript process off. It's eating up too much memory for something I have no use for.
Is there a way to kill this apart from uninstalling Visual Studio 2017 and switching back to Visual Studio 2015?
Killing the main process in Task Manager doesn't affect anything in Visual Studio. However, if I go to the Details tab and kill the individual running processes, it crashes Visual Studio. I took a video of what happened after I killed the process and ran my local web page (sorry for the quality; Stack Overflow limited image size to 2 MB):
Upvotes: 147
Views: 39256
Reputation: 8804
I raised feedback on this issue:
Visual Studio 2017 - Node.js Server Process - Turn off?
I got a response back from the Microsoft team - he directed me to this post:
Node.js server-side JavaScript process consuming too much memory
The node.exe process has the command line:
Effectively I was told:
In Visual Studio 2017, several features are implemented in JavaScript. Node.js is used by Visual Studio to run that JavaScript. Among other things, Node is used to run the code that provides formatting and IntelliSense services when a user is editing TypeScript or JavaScript. This is a change from Visual Studio 2015.
Upvotes: 34
Reputation: 1242
In my case I did not want to kill the Node.js process, and I did the following things to lower the CPU consumption of Node.Js processes that run under Visual Studio 2019:
npm rebuild fsevents
It now seems much better to me. But not 100% unfortunately.
Upvotes: 0
Reputation: 27
To disable Language Services in Visual Studio Code, go to extensions, then filter on built-in extensions and disable the TypeScript/JavaScript language service.
I finally discovered this after Visual Studio Code's Node.js service crashed my server about a million times. It was annoying that this was so hard to find documentation about.
Upvotes: -2
Reputation: 875
Something that can help the projects mitigate the Node.js weight is to reassign the node version used under menu Tools → Options → Projects and Solutions → Web Package Management to an installed 64-bit version. Visual Studio will still launch its internal Node.js process for a tsserver.js instance, but any TypeScript code in the project will default to the supplied version -- and this helped me firsthand.
Also, another time I found the language service to be running down, I discovered using a simple tsconfig.json file above the directories used as repositories, and specify to skipLibCheck: true
, and add node_modules to exclude—it tremendously helped along the service, and one file does all folders beneath it, regardless of direct project references. P.S.—if you do want JavaScript intellisense support still, make sure to set the allowJs: true
and noEmit: true
option.
Lastly, verify in the TypeScript Options under the menu Tools → Options → Text Editor → JavaScript/Typescript → Project that it is not checked to Automatically compile TypeScript files which are not part of a project since that can also tie up resources for auxiliary third-party projects using Node.js or TypeScript.
These are not foolproof. Each has to find their exact bottleneck, but I have found these have worked for me and my team more often than not.
Upvotes: 4
Reputation: 111
I am just noting that the high-memory consumption has been fixed in the 2017-05-10 version of Visual Studio 2017 (version 15.2, 26430.04) release.
Release notes are at Visual Studio 2017 version 15.9 Release Notes.
Specific notes about the fix are at Node.js server-side JavaScript process consuming too much memory.
Upvotes: 1
Reputation: 569
Ryan Ternier's answer pointed me in what I believe is the right direction. Following his link led me to Bowden Kelly's answer, right beneath the accepted answer.
Here is Bowden Kelly's answer:
The node process you are seeing is powering the JavaScript language service. You will see this process appear anytime you edit a JS file, TS file, or any file with JS/TS inside (html, cshtml, etc). This process is what powers IntelliSense, code navigation, formatting, and other editing features and it does this by analyzing the entire context of your project. If you have a lot of .js files in your project, this can get large, but more than likely the issue is that you have a lot of library files that are being analyzed. By default, we will scan every .js/.ts file in your project. But you can override this behavior and tune the language service to only focus on your code. To do this create a tsconfig.json in your project root with the following settings:
{
"compilerOptions": {
"allowJs": true,
"noEmit": true
},
"exclude": [
"wwwroot/lib" //ignore everything in the lib folder (bootstrap, jquery, etc)
// add any other folders with library code here
],
"typeAcquisition": {
"enable": true,
"include": [
"bootstrap",
"jquery" //list libraries you are using here
]
}
}
Once I added the folder with all my script libraries into the tsconfig.json file, life was good again.
Upvotes: 18
Reputation: 897
You have to disable TypeScript support in Visual Studio:
Menu Tools → Extensions and Updates → TypeScript for Microsoft Visual Studio → Disable.
After that, just restart Visual Studio, and you are good to go.
Upvotes: 19
Reputation: 2974
In menu Tools → Options → Text Editor → JavaScript/TypeScript → Language Service...:
Uncheck 'Enable the new JavaScript language service'.
Restart Visual Studio
This appears to prevent the Node.js process from starting.
Upvotes: 210
Reputation: 8721
The dirtiest workaround ever: just rename the ServiceHub.Host.Node.x86.exe
to something else. It hasn't bothered me since. When (if) you actually need it, just rename it back.
The same trick works in Adobe Photoshop which also runs Node.js for some reason I haven't discovered in my usual workflow yet.
You can't just rename it and expect things to keep working. Who knew!
Apparently this renaming trick only works if you suspend the Visual Studio process, kill Node.js, and then resume Visual Studio. If you try to launch Visual Studio with the Node.js EXE file renamed, it will crash when opening a project with an "unknown hard error".
Also, while working on an already loaded project, the lazy reference counter above methods and properties won't work because apparently that relies on Node.js being there somehow.
So it might be okay to just suspend the Node.js process and let Windows paging swap its memory out from RAM onto the hard drive, without renaming the EXE file, so you could start Visual Studio again later without going through the renaming hassle. If you're willing to live with the consequences, that is.
Upvotes: 6