VS 2017 Build very slow

Reported by Christian Jelinek Mar 30, 2017 at 09:42 AM fixed in: visual studio 2017 version 15.5 windows forms windows 10.0 visual studio 2017

After updating to VS 2017 I've found that builds of our relatively large WinForms application have become extremely slow. The main "shared/common" project with about 300k LOC took about 18 seconds to build with VS 2015, but now takes 1 minute 8 seconds to complete, being about 3.5x slower. Multiplying this slowdown across the 27 projects total makes for a very miserable development experience.

Additionally to the problem steps recording (which may show basically one minute of nothing if you don't trace the compiler?) I've performed one CPU sampling perf trace of VBCSCompiler.exe during the build of the aforementioned project, but I'm not sure how useful this is going to be. If you have any instructions or hints on what else to look for I'd be eager to help.

Add comment Show 17

Fagner Antunes Dornelles · Apr 18, 2017 at 08:48 PM 0

I'm with the same problem. Waiting too.

Shelby Suski · May 02, 2017 at 09:29 PM 0

Having similar issues at https://developercommunity.visualstudio.com/content/problem/49785/visual-studio-2017-toolset-slower-to-build-than-20.html. Builds are approximately 30% slower for me.

Peter Palotas · Jul 05, 2017 at 08:33 AM 0

We have the same problem here as well. A solution of about 200 projects takes much longer to build with VS2017 compared to VS2015. This appears to affect our build servers as well. What is going on here?

Daniel Schipper · Jul 21, 2017 at 06:51 PM 0

Same here - way slower.

Nicki Zabell · Aug 09, 2017 at 12:43 PM 0

Same here. We call msbuild from FinalBuilder and gets theese build times:

First run:
msbuild v14: 3m 43s
msbuild v15: 6m 46s

Second run:
msbuild v14: 0m 39s
msbuild v15: 3m 41s

Ty Overby [MSFT] Nicki Zabell · Sep 11, 2017 at 10:19 PM 0

Ni Nicki! Since you are able to run the compiler both before and after the upgrade, could you take ETL traces (using perfview) during the build process from both before and after?

You can download perfview here: https://www.microsoft.com/en-us/download/details.aspx?id=28567

Collecting systemwide traces can be done in perfview by hitting alt-c and then manually clicking "start collection" and "stop collection"

Nicki Zabell Ty Overby [MSFT] · Sep 12, 2017 at 08:09 AM 0

Hello Ty.

I did a run with msbuild v14, which resulted in a PerfViewData zip file, with a size of 141 MB.
Can I somehow filter PerfView to only collect msbuild data, or are you interested in all processes?

Show more comments

Scott Merilatt · Aug 22, 2017 at 03:07 AM 1

EDIT - this is not a solution, just a "me too". Same here. In 2013, 2-3 seconds. In 2017 > 2 minutes. Small solution, 1 winform project with 1 form, a class library project with 5 class files (3 of those are just POCOs), and a test project (NUnit) with 5 test fixtures in it. Another solution has a console app with maybe 3 classes in it and a class library with 6 classes in it, no unit tests, and takes just as long to build. I have tried the solutions (e.g. turn off codelens, turn off auto-adjust performance, turn off resharper, etc, etc) found on stack overflow (https://stackoverflow.com/questions/42877071/visual-studio-2017-is-too-slow-during-building-and-debugging) and the tips to speed up resharper (https://www.jetbrains.com/help/resharper/2017.1/Speeding_Up_ReSharper.html) to no avail. I posted the links as those solutions may be be of use to someone else.

Syed Wasti · Aug 31, 2017 at 01:47 PM 0

Same problem for me. Build time on VS2015 was extremely fast on my WCF project but it has slowed down since i upgraded to VS2017.

Harshit Tomar · Oct 20, 2017 at 04:13 PM 0

that's true, I'm having the same problem.

Ashok Kamath [MSFT] · Oct 26, 2017 at 02:16 PM 0

Thank you for your feedback! We have fixed the problem in an upcoming release (15.5). Thank you for helping us build a better Visual Studio!

Nick Thompson · Feb 14 at 05:07 PM 0

I have found the reason for the the poor performance of msbuild in our project. Our debug/release folders contain two junction points to a folder that would normally be present if the project was in its "deliverable" state. On our development system these folders contain millions of files (for good reasons that are out of the scope of this discussion). Looking at the diagnostics log it appears that msbuild is performing a full index of all of these files for every project it builds, even though they are not controlled by the solution in any way. This is increasing build time at least 100 fold. Removing these junction points and replacing them with a file containing a redirection path solves the issue. We are moving from VS2008 (finally) and that did not have this issue.

Show more comments

Added a solution by David Mulholland · Nov 17, 2017 at 04:21 PM

Me too. Very large winforms solution with multiple projects. Takes approximately twice as long to compile (from 3 minutes up to 6 minutes for a full re-build). Had to go back to 2015 as couldn't live with the pain.

Add comment · Share

Added a solution by Gerardo Recinto · Nov 22, 2017 at 07:21 PM

Me too, I noticed vs2017 build very slow as compared to vs2015, especially on large solution (many projects).
What helped me is to follow the optimization recommendations by people (setting Source Code to None, set Windows to "best performance", ...) AND this one, my own:
* Set the Host computer's setting to optimize on "Background Services" using Windows' properties, Advanced System Settings, Advanced, Advanced tab.

It seems VS2017 as it has a more responsive UI, that the background workers are given less chance to do their work. Prioritizing on background services seemed to have help.

Add comment · Share

Added a solution by Richard Griffiths · Nov 23, 2017 at 10:58 AM

No solution here either. I had to crash it out yet again with switch around in the program at all causes inexplicable pauses and hold-ups. Any designer screen, XSD designers, dbml, anything actually.

It's a large winforms project for sure but on an I7 with 32gb and twin raid SSD's, I'd expect a bit more fluidity to my work. This is 15.4 now.

Add comment · Share

Added a solution by blah blah · Nov 25, 2017 at 05:47 PM

I have this problem too. VS2017 is 5.7 times slower than VS2015 in a solution with 36 projects. VS2017 is unusable in its present form.

I have this problem too. One build with 36 projects took 5.7 times longer in VS2017 Community vs VS2017 Pro. There's no way VS2017 is usable in its present form.

Add comment · Share

Added a solution by Daniel Schipper · Nov 25, 2017 at 06:12 PM

This worked for me

https://developercommunity.visualstudio.com/content/problem/83893/slow-compile-times-compared-with-vs-2013.html?childToView=111849#comment-111849

Add comment Show 1 · Share

Adi Shavit · Nov 26, 2017 at 11:23 AM 0

Will try.
Is there a way to get CMake to do this automatically(other than tell to to copy the file into the solution folder)?

Does this apply to non-managed C++ code?

Added a solution by Daniel Schipper · Nov 25, 2017 at 06:12 PM

This worked for me

https://developercommunity.visualstudio.com/content/problem/83893/slow-compile-times-compared-with-vs-2013.html?childToView=111849#comment-111849

Add comment · Share

Added a solution by Maly Lemire · Nov 29, 2017 at 07:41 PM

This does not resolve the slow build but helps me do something else while building.

Each time I open VS2017 and build I go in task manager and set VBCSCompiler.exe priority "Below normal".

After that VS is more responsive while building.

PS : I have a solution with more than 100 projects that mix MVC, WPF, WinForms, ASP.Net core, .Net 4.7.1 and .Net Core 2.0

Add comment Show 1 · Share

Nicki Zabell · Nov 29, 2017 at 08:05 PM 0

Nice tip, thank you.

Added a solution by Maly Lemire · Dec 04, 2017 at 08:54 PM

Just updated to 15.5.

Still slow as before... especially on a large class library project with around 2000 files that result in a 25mb dll.

It takes about 1.5 minute to build.

Add comment · Share

Added a solution by Blair Wang [MSFT] · Dec 05, 2017 at 06:49 AM

This issue has been fixed and is now available in our latest update. You can download the update via the in-product notification or from here: https://www.visualstudio.com/vs/ Thanks to everyone who provided feedback, votes and solutions for this problem.

Add comment Show 2 · Share

cathy · May 26 at 03:55 PM 0

Not fixed, visual c++ unmanaged code on 15.7.1 very slow build time compared to VS 2015.

Roi Chen [MSFT] ♦ cathy · Jun 01 at 08:56 AM 0

Hi cathy, Can you create a new report by using Report A Problem in Visual Studio (It's on the Help Menu under Send Feedback)since this issue has been closed for a long time? Thank you for your patience.

Added a solution by Nicki Zabell · Sep 15, 2017 at 05:53 PM

I did a lot of tests, even ran custom builds of MSBuild, and suddenly the official MSBuild 15 was blazing fast. It looks like the delayed ngen from installing VS 2017 just wasn't finished. Why it took so many days I can't explain. If you can, perhaps try forcing ngen to finish and see if that helps:

ngen executeQueuedItems

Add comment Show 1 · Share

Christian Jelinek · Oct 10, 2017 at 01:53 PM 0

This unfortunately didn't work for me. While ngen did a lot of compiling on my system (though I had just recently installed the VS 15.4 update and SMSS 2017, which might explain the workload), builds are still as slow as before.

Developer Community

Get help from our community supported forum

VS 2017 Build very slow

Solutions

Try Microsoft Edge

Developer Community

Get help from our community supported forum

VS 2017 Build very slow

Solutions

Related Problems