Node Projects in Visual Studio are taking twice as long as to build

[NoelAbrahams]

• NTVS Version: 1.4.20802.1
• Visual Studio Version: 2017 15.8.4
• Node.js Version: 6.2.2

Node JS projects are taking twice as long to build as standard TypeScript projects (creates via the ASP.Net project types).

This is quite noticeable in large solutions.

Is there a way to profile this to see what's causing the slowness?

I should add that there is nothing special about the code in the projects. They are pretty much identical across Node and non-Node projects; just standard TypeScript.

[NoelAbrahams]

Is anyone out there? 👻

[NoelAbrahams]

I've noticed something else. It looks like the Node projects are building synchronously. For example, on a non-Node TypeScript set of projects, I see the following on the output screen:

10>------ Rebuild All started: Project: AAA, Configuration: Debug Any CPU ------
11>------ Rebuild All started: Project: BBB, Configuration: Debug Any CPU ------
12>------ Rebuild All started: Project: CCC, Configuration: Debug Any CPU ------
13>------ Rebuild All started: Project: DDD: Debug Any CPU ------
14>------ Rebuild All started: Project: EEE, Configuration: Debug Any CPU ------
15>------ Rebuild All started: Project: FFF, Configuration: Debug Any CPU ------


11>  BBB -> C:\BBB\bin\BBB.dll
10>  AAA -> C:\AAA\bin\AAA.dll
15>  FFF -> C:\FFF\bin\FFF.dll
13>  DDD -> C:\DDD\bin\DDD.dll
14>  EEE -> C:\EEE\bin\EEE.dll
12>  CCC -> C:\CCC\bin\CCC.dll

For each project there are two entries. One showing the asynchronous start of the build and the other showing the build completion. (The first set of entries are printed in quick succession.)

However, for the NTVS projects, I only see one entry per project:

35>------ Rebuild All started: Project: SSS, Configuration: Debug Any CPU ------
36>------ Rebuild All started: Project: TTT, Configuration: Debug Any CPU ------
37>------ Rebuild All started: Project: UUU, Configuration: Debug Any CPU ------
38>------ Rebuild All started: Project: VVV, Configuration: Debug Any CPU ------
39>------ Rebuild All started: Project: WWW, Configuration: Debug Any CPU ------
40>------ Rebuild All started: Project: XXX, Configuration: Debug Any CPU ------
41>------ Rebuild All started: Project: YYY, Configuration: Debug Any CPU ------
42>------ Rebuild All started: Project: ZZZ, Configuration: Debug Any CPU ------

The key thing is these projects appear to be building synchronously. Each line takes 4-8 seconds to print. Unlike for the standard TypeScript projects, there is no corresponding second entry.

Visual Studio schedules builds on all available CPU cores. Does anyone know why this is not happening for Node projects?

[NoelAbrahams]

Hey, guys, I just spoke to my pal Satya Nadella and he says whoever fixes this will get a promotion and a Christmas bonus.

[amcasey]

Hey @NoelAbrahams, sorry for the delay. I think we had a separate thread about this on the TS repro. Is there anything left to do here?

[NoelAbrahams]

Hi, @amcasey this is still an outstanding issue: NodeJS projects do not build in parallel in Visual Studio. I've upgraded to VS 2019 and the issue is still there.

[amcasey]

@NoelAbrahams Thanks for confirming! We'll look into it.

[NoelAbrahams]

@amcasey is there a fix for this? Happy to test and provide feedback.

[amcasey]

@NoelAbrahams Sorry, we've had a lot on our plates (the same team supports a lot of non-Node scenarios) and this has yet to rise to the top of the stack. We haven't forgotten about it though. Thanks for your patience.

[rakatyal]

@NoelAbrahams: I took a jibe at this and I did conclude that node projects in a VS solution do build in parallel permitting the presence of available cores. The output you see in the window comes from build targets file which varies based on the different project systems (ASP.Net, NodeJS etc), but it doesn't reflect async or parallel behavior of the build process.

That being said, I would like to understand why you see difference in performance based on your project types. Could you tell me more about the projects you are comparing? There is a lot of underlying dependencies of different project systems in VS which might cause difference in build times.

Also if you are curious and want to investigate build timing issues, you can use msbuildlog to dig more.

[NoelAbrahams]

@rakatyal thanks for looking into this.

The projects I'm comparing are

ASP.Net Web Application (ProjectTypeGuids: {349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc})

and

Blank Node.js Web Application (ProjectTypeGuids: {3AF33F2E-1136-4D97-BBB7-1795711AC8B8};{349c5851-65df-11da-9384-00065b846f21};{9092AA53-FB77-4645-B42D-1CCCA6BD08BD})

All projects only contain TypeScript code. There is nothing else (ie no C# or anything else). The only difference between the two project types is that the NodeJS projects are based on the CommonJS framework (ie. TypeScript compiler option module: commonjs), while the ASP.Net projects are based on namespaces (ie. TypeScript compiler option module: none)

If I select a set of the ASP.Net projects and build them then I get the output as expected: output in random order. But if I select a bunch of Node.Js projects then the output is a bit strange because the projects always seem to build in the same order. The build is also much slower.

I recently upgraded from a 4-core to an 8-core machine, but failed to see any improvement in the NodeJS projects.

Just as a start, do you know why the output from the NodeJS projects are always in the same order? I wouldn't expect this if they are being built in parallel.

[rakatyal]

@NoelAbrahams: A solution build inside VS is controlled by something called 'Build Solution Manager'. In simple terms, when there are multiple projects in a solution, it creates a dependency tree (with the help of the project system those projects belong to) and then triggers parallel builds on available cores based on this tree (The number of available cores are automatically detected or controlled by Tools -> Options -> Projects and Solutions -> Build and Run). Once a project is built and the core becomes available, the build manager hands it the next project in the dependency tree and so on.

A single project build is handled by the project system itself, but the parallel triggering of builds is done by the Solution Build Manager and that should be same across all project types.

Now as I mentioned earlier, the output you see in the windows inside VS comes from the project build target files which differ according to the project systems. Why ASP.NET provides random order and NodeJS do not, I am not sure. The order might just be the order in which projects are present in the solution file. But rest assured, this does not indicate that projects are not being built in parallel.

[NoelAbrahams]

@rakatyal thanks for the background info. Let's establish a couple of things:

• I do have a multi-core machine.
• Visual Studio is using all available cores to carry out the builds.

In short, there are no configuration or hardware problems associated with the issue.

I just ran a simple test: In Visual Studio I selected 9 projects of each type and built them. Here are the results:

• ASP.Net projects - 14 seconds.
• NodeJS projects - 44 seconds.

The Node projects have much fewer files. Here are the metrics

• ASP.Net projects: 381 files, 25K lines-of-code.
• NodeJS projects - 59 files, 7K lines-of-code.

It does look like something really strange is going on if the NodeJS projects are taking 3 times as long to build with a much smaller set of files.

Are you able to see similar metrics yourself? What happens when you create say 4 NodeJS projects in Visual Studio and build them?

[rakatyal]

@NoelAbrahams: What results do you see when you build single projects? Did you try using the tool I mentioned before for detailed analysis?

There seems to be 2 different questions here. One is your query if the Node projects in a solution build differently than others (which I have already established is not true and handled by the VS solution build Manager and not the project system) and the other seems to be concerning build time of one project type vs other. Are you now looking for answers on the latter?

[NoelAbrahams]

@rakatyal yes, I'm looking for answers to the latter; that should be clear from the title of the issue.

I only mention the parallel build (or lack thereof) because I thought that might be a potential reason for it.

The individual project build times are as follows:

• ASP.Net project - 7 seconds.
• NodeJS project - 6 seconds.

Can you tell me how is it that one NodeJS project builds in 6 seconds while 9 projects take 44 seconds on a machine with 8 cores?

What sort of detailed analysis do you want me to carry out? I'm actually trying to report a bug in your systems.

[rakatyal]

@NoelAbrahams: Thank you for all your help and investigations so far. We are just trying to root cause the issue and hence the follow ups :)

I did take a more deeper look into this and there might be something quirky, particularly about the NodeJS TS Web App Project type. I think your initial assessment that project builds are not happening as expected (in parallel) might be right.

I validated this by trying out the command line msbuild to build the VS solution. I noticed that my solution with multiple NodeJS Web App projects build significantly faster via that. I am working on figuring out why the VS Solution Build Manager isn't doing what it's supposed to. Meanwhile, if you are trying to have better build performance (and also validate what I found), you can try doing this as well.

1. Open the developer command prompt for Visual Studio.
2. Go to your project folder where the solution file exists.
3. Run msbuild <solution_name>.sln -m. The -m flag is for msbuild to build projects in parallel.

Let me know if you notice any changes. I will update here once I find out more.

[NoelAbrahams]

@rakatyal, yes a MASSIVE improvement.

This is what I get for a set of nine projects.

• Using Visual Studio - 42 seconds.
• Using MSBuild (msbuild service.sln -m -t:rebuild) - 8 seconds.

The 8 seconds is definitely what I'd expect given the multi-core setup we have.

Please let me know if you need me to check anything else. It would be great to see this fixed in Visual Studio as it's really not possible to run the command line as part of the normal workflow.

[NoelAbrahams]

@rakatyal are you still investigating this issue? No rush: it's only been five months.