144

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?

Enter image description here

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):

Enter image description here

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Ryan Ternier
  • 8,714
  • 4
  • 46
  • 69
  • 1
    Are you using TypeScript? – SLaks Mar 13 '17 at 16:50
  • We're using a small amount of it. – Ryan Ternier Mar 13 '17 at 17:13
  • I've ended that process and haven't seen any ill-effects. Web-compiler compiles LESS files without it. – Glen Little Mar 15 '17 at 00:22
  • @GlenLittle That does work, but like the cat... it came back. I'm wondering if it's something installed at the beginning and is always running. I just installed VS2017 on my lappy and it gave me the option to install the server. I'll update this when I test on it – Ryan Ternier Mar 15 '17 at 23:07
  • Can you file a feedback item about this? There's a few different features in the web dev tools that use Node under the hood (such as the JSLint/CSSLint/etc) that might be involved here. These would show up for any web project, not just TypeScript or Node. – Jimmy Mar 16 '17 at 17:46
  • Which path is this node.exe spawned from? There are two teams in VS (that I know of) which spawn a child Node process, but they come from different paths. It'll help me route this feedback to the correct folks. – Jimmy Mar 16 '17 at 18:50
  • The process starts as soon as I load any page from my solution in a browser. ASP.NET MVC. If I delete it, it just comes back without any issues. – Ryan Ternier Mar 16 '17 at 20:53
  • @RyanTernier can you confirm the path to node.exe for this process? Does it match %VSInstallDir%\Web\External\node.exe? – Jimmy Mar 17 '17 at 07:35
  • @Jimmy Yes: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Web\External – Ryan Ternier Mar 17 '17 at 16:48
  • This isn't really an answer but is feedback for @jimmy. I happen to be using Typescript at the moment, and see this in the Task Manager. The TypeScript 'tsserver' is taking 600MB of RAM (more than the entire DevEnv!): [![enter image description here](https://i.stack.imgur.com/d7eNf.png)](https://i.stack.imgur.com/d7eNf.png) – Glen Little Mar 16 '17 at 23:55
  • I've heard from another @ MSFT that the compiler + VS use the Node.JS process to do a bunch of jobs for browser link and the like for debugging. He's not on the VS team, so I'm not sure if it's accurate – Ryan Ternier Mar 17 '17 at 16:41
  • @RyanTernier it's true that the JavaScript/TypeScript language service uses node as well, but they use their own copy separate from the one giving you grief. This bothersome one belongs to my team. – Jimmy Mar 17 '17 at 17:33
  • Thanks, I'll file a bug on this as well. And also feel free to submit feedback, we try to place more weight on issues reported by customers. Worst case, my bug will get matched to yours. ;) – Jimmy Mar 17 '17 at 07:26
  • @jimmy - for you. – Glen Little Mar 16 '17 at 23:55
  • @Jimmy Our solutIion was built (not a recommended setup) where there's a base UI project that contains all common views/scripts, and during build steps it copies the contents to every other MVC project. Due to this all scripts are duplicated in source code (only on our dev boxes). This might be the reason why this might be so high given the data I have. Does the Node.JS process have the ability to filter out loading additional files if a similar one is already in memory? – Ryan Ternier Mar 20 '17 at 21:52

9 Answers9

204

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Andy Taw
  • 2,794
  • 1
  • 17
  • 9
  • 20
    This solution helped, should be upvoted. But you need to restart visual studio for this to take effect. – madd Mar 23 '17 at 12:27
  • 17
    I did this, rebooted VS2017 an it still did not prevent "Node.js: Server-side JavaScript" from starting when I started VS2017. Its hogging about 800MB on my machine and I can no longer debug in Chrome. – Bill Mar 30 '17 at 18:25
  • 1
    Same problem here @Bill - disabling the TypeScript extension as per Gabriel's answer seems to have sorted it though. – Dunc May 15 '17 at 13:50
  • What exactly this service do? Is it ok to disable it? – HamedH Jun 05 '17 at 07:03
  • 1
    What the hell? Why is that doing in Text Editor settings? :P – Sнаđошƒаӽ Jun 13 '17 at 12:29
  • wow on the money ... dotnet run worked as an alternative but i wanted to launch multiple projects so thanks for the tip. – hidden Jul 05 '17 at 03:22
  • I had 30 node.exe processes running. Very annoying. – Brain2000 Oct 25 '17 at 17:27
  • 4
    This isn't even an option for me in my menus – BradLaney Dec 01 '17 at 19:52
  • 1
    Shame on Microsoft for making this a default, and running automatically, it basically was crashing my computer every single time. No wonder people are trying to move away from clunky systems like Visyual Studio. – William Howley Jun 11 '18 at 14:58
  • I needed to upgrade VS 2017 to the latest version for this fix to work.. 15.9.4 – phil Dec 14 '18 at 20:16
  • 1
    Make sure you also check the "Disable dedicated syntax process (restart required)" option. Also note that there will always be a Node.js process open, consuming around 11MB. – Rich_Rich Jan 15 '19 at 19:22
  • This is GREAT! My VS was sluggish as hell, always running at 50% or so while and my Mac side CPU was at 220%! After this change, no more sluggish, Win CPU down to 0.5-1% while running my project, and Mac CPU down to 25-35%! Thanks!! EDIT: Mac CPU down to around 7% it seems after a minute – Robert Benedetto Apr 15 '19 at 04:05
  • Confirmed it works, Node.js CPU down from 20-30% to 0% on VS 2017 15.9.12. – Conan May 25 '19 at 17:45
34

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:

Enter image description here

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Ryan Ternier
  • 8,714
  • 4
  • 46
  • 69
  • Indeed it's a thing to make the main VS process more responsive and optimize performance by lazifying certain things like Intellisense into another process, and with more ram for each 32-bit process. But that doesn't matter for us in this case. What I've found is that Node consumes more memory if you have more source code files open and Intellisense enabled. If you're really running low on memory, experiment with disabling Intellisense and other features you could do without. – user1306322 Mar 18 '17 at 14:19
  • 3
    It has had the opposite effect for me and has made VS2017 so lazy (pun intended) that I'm going back to VS2015. I find it rediculous that MS have to use 3rd party external frameworks to do something as simple as Intellisense. That has always been one of their strengths ...and now? I have disabled TypeScript and Node.js and if I just look at Chrome VS2017 hangs so badly I sometimes have to reboot. So back to Firefox and VS2015 for me, at least for now. And this is on an i7, 16GM RAM and all SSD setup with Win10 Pro. Shocking. – Neville Aug 10 '17 at 15:04
  • according to the post referenced here ... Disabling the TypeScript extension is a work around for the moment, at least for me. Click Tools, Extensions and Updates, search for "TypeScript" and disable it. Restart Visual Studio. – pat capozzi Oct 01 '17 at 16:09
  • Well, that explains why Intellisense has gone to hell. – Andy Nov 07 '17 at 21:06
19

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Gabriel
  • 887
  • 10
  • 22
18

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Ralph
  • 559
  • 4
  • 14
  • 1
    After my soap box whinge in the previous answer, this seems to have saved the day!!! Such a simple thing yet so obscure and only took me three days of battling with VS2017 to finally find this! – Neville Aug 10 '17 at 15:47
  • Adding this file lead to all kinds of TypeScript errors when I built the project. Removed it and the errors went away. – John81 May 01 '18 at 11:44
6

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.

It turns out...

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user1306322
  • 8,561
  • 18
  • 61
  • 122
  • Unfortunately, I think there's some code that will detect if the node process is unresponsive and launch a new one instead. I'm not familiar with that part of the VS code, but that's how it was described to me. – Jimmy Mar 17 '17 at 17:58
  • I always like the idea of *depriving by force*, you know what I mean... ;-) – Sнаđошƒаӽ Jun 13 '17 at 12:31
3

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Nathan Teague
  • 825
  • 6
  • 11
  • This worked for me. Added 'C:\Program Files\nodejs' (where I've previously manually installed NodeJS), to the top of this list, and the Node.js process went from 50-60% CPU load to 0%. – andynil May 25 '18 at 00:57
  • what do you mean top of the list - which list exactly?? – immu Mar 29 '22 at 18:21
1

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
zulumojo
  • 111
  • 1
  • 4
  • 2
    Running 15.2 (26430.16) here and I'd say that maybe they fixed a ridiculously--high-memory consumption issue but only manged to downgrad it to high-memory consumption :) – PJUK Aug 14 '17 at 14:10
  • 1
    Agreed. The problem is mostly due to how poorly written node.js is in the first place (in that "object" functions are replicated over and over again) - then again, frameworks to patch JS's shortcomings will always make things slower. This is what happens when you have Linux people develop for Windows - a big fat convoluted mess. – MC9000 Aug 17 '17 at 01:15
  • I reported this issue at https://github.com/aspnet/JavaScriptServices/issues/1298 I observed this issue with VS 2015 in 2015 with the JavaScript projects, but the problem is becoming more worse. – wonderful world Sep 24 '17 at 17:42
  • stil going 2 gb on 2017 – Geomorillo Oct 28 '17 at 15:08
  • Not fixed for me. Still eating up tons of memory with version 15.6.6 – John81 May 01 '18 at 11:37
  • version 15.9.25 and it's still jacked. Andy Taw's plan helped significantly. 1 remaining Node.js instance using 'only' 10-13Meg at this point. – Joe Johnston Sep 10 '20 at 20:37
0

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:

  • I removed folder "Program Files (x86)/MicrosoftSDK/TypeScript
  • I run npm rebuild fsevents
  • I turned this off in Chrome browser: Settings-System-Continue running background apps ...

It now seems much better to me. But not 100% unfortunately.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Honza P.
  • 1,165
  • 1
  • 11
  • 12
-2

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.

Disable the built-in TypeScript/JavaScript language service extension

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Ben Olayinka
  • 27
  • 2