I must work with a Visual Studio (2017) Solution that contains 654 projects, and counting. The projects are a mixture of C++ and C# projects - possibly 2/3 C++.
The problem is, VS2017 (we're already running 15.8) is highly unstable at this project count, but for some tasks I need to open the whole solution.
One can (and should) question the design, but please not here. Are there any viable tricks to make working with such a sln bearable?
The problems we have is:
After having fully loaded, it's sluggish as hell, even on our beefy dev machines. Hangs often.
It will crash many times a day. (We isolated a few cases that reliably crash it, like oping the C++ setting dialog, but it's still unstable).
Crashes are often observed when VS peaks at ~ 2.6GB RAM
Not Problems:
Solution load times: The solution is loaded in a decent amount of time. We don't need to optimize for this at the moment.
Compilation times: Devs don't do full-solution builds anyway. (But some tasks require having your corner in the full context of the whole solution.)
I already tried disabling VS Intellisense, but it didn't help. Disabling our VisualAssistX plugin also didn't really help.
Historically the VS team has always said that they're going to fix the problem of VS loading too much at some indefinite point in time. That's one reason why they
haven't made it 64-bit yet as well. Now that they've disabled the selective loading API, you're pretty much on their mercy.
For older VS versions, there's Funnel.
It allows you to selectively load a subset of the projects, automatically loading dependencies. The added benefit is that refactoring, search etc. only works in context of loaded projects, making it much faster. You can also save and organize your filters, making it easier to switch between different subsets.
I keep having intermittent issues with visual studio 2010: I'm working on a rather large solution (200+ projects), so the whole solution takes a long time to build even with a little change.
I often need to debug processes on remote machines.
What I noticed is that visual studio would often appear hung on detach or terminate remote process. On closer examination, it appears that immediately after debugger disconnects, VS will start to build solution, and it is not possible to cancel the build by pressing Ctrl+Break, in fact no menus work at all until the build finishes or fails, and with large solution it takes a long time. One way I found which would fix this issue is killing the MSBuild.exe processes, spawned by VS, which would fail the build.
Have anyone seen this behavior? Is there any fix? Very annoying
EDIT: This is how the process explorer looks after disconnect from debugger: http://vvcap.net/db/oz1NMoyXnWWlQp8mWaRY.htp
This would happen when you edit code while a breakpoint is active. After the debugging session ends, VS automatically rebuilds the solution to incorporate the changes into the binaries, not just in memory. This does tend to make VS a bit catatonic, I think it tries to prevent you from doing anything that would interrupt that operation. This normally doesn't take more than a couple of seconds but I have no idea what might happen in such a large solution. Disabling E+C is probably not one of the workarounds you'd contemplate if you are used to being able to edit code while debugging.
Having solutions with 200 projects does tend to test the limits of endurance. Do try to whittle it down to a core set of projects, chucking out the ones that shouldn't change because doing so would break too much code in higher layers. Or just create another solution and include only the projects you want to test. It doesn't otherwise affect the debugging session, you can still debug code from such projects as normal. Without E+C of course.
Such amount of projects in a solution file can take a LOT of time to build. I can't (myself) imagine) the worries before pressing ctrl+b (know that takes 30 seconds of my working hours).
I would tell my boss that we are in badly need of insert a 40 hour delay because of refactoring the projects into maintanable & compilable parts (sharing same dll into each library per purpose/layer). If the delays is about pure project redefining or just splitting out the solution into several projects fully depends on your work. At least the parts where I am expecting problems and are about to change,
I have just upgraded to VS 2010, and I have performance problems which I did not have before (in VS 2008).
The most annoying thing is that it freezes while I work in the text editor. Sometimes when it freezes I see that it is saving auto recovery information, but not always.
Almost anything I do gives an unacceptable long delay, like saving, starting to debug, ending debug session, switching between design and code view, and doing WinForms designing.
I have some parts of my home directory on a mapped network drive. I suspect that that might be a part of the problem. Is it possible to configure VS 2010 to use exclusively local disk for its "internal" work perhaps?
Any hints would be appreciated! Has anyone else experienced these kinds of problems?
Edit:
I forgot to give my specs:
Win 7 64-bit
4 gb memory
No addins, just standard installation
The project folder is on the network drive
One interesting thing is that I feel that I have better performance in a VM running XP (where the VM runs on the same PC).
VS is great if you do what microsoft recommends and work on a local copy of your projects.
As soon as you start tying to open projects in remote locations you will get this issue.
Recommendations:
use a source control solution.
create a copy of your project locally and run the solution from that.
Also ...
I think it does it's clever stuff in the background, I found the more i use it the faster it gets, especially on long running projects that I regularly go back to.
If you think it might be aformentioned WPF framework you may want to try switching off aero (as a test) if it helps the problem is likely that your chosen graphics hardware is not very good at effect or 3D based output so it's struggling.
Also try reducing the number of background services and apps you have running.
on windows 7 these days 4 gigs of ram is considered standard, so whilst it should perform fine maybe consider putting more ram in if you are trying to handle large datasets / similar business applications.
Another thing you could try is run a repair install over the top of your existing, it may not have cleanly installed something ... unlikely but it may help.
If you can, buy an SSD disk and move all your projects locally.
I find VS2010 super intensive on disk.
It fly on my home machine with an SSD but it's almost unusable on my work machine(Win7 4 gig RAM, but standard disk)
Try setting the number of parallel builds to half the number of cores you have (I think its in options, settings, Solutions and Project, build and run).. I had it set to 8 which was too much.. it spawned 8 msbuild.exe, rebuilding a solution with 70 projects bottlenecked the disk when they all tried to read/writte similar pre-compiled headers. Those msbuild's stick around even after you close the IDE.
Also I disabled the gather browsing info for implicit files, which made intellisense parsing quicker.
An old post I know, but in case it helps others (as the previous answers focused on source code)...
I found that it wasn't my source code that was the issue, that was held locally along with all the references, but the default locations (project, project templates and item templates) as these were held on a networked drive. These can be altered in the Tools -> Options -> Projects and Solutions.
Alternatively you could change the frequency of the saves or turn them off altogether via Tools -> Options -> AutoRecover
I wanted to know if it is possible to know why a Visual Studio 2005 (MSBuild) build is taking a long time to build a project.
Suddenly we are getting 7-minute build times on some computers, while others take less, such as 4 minutes.
So I think I need to identify changes that were made to the project and are causing a longer build time.
Any ideas on how I can do that?
Take a look at MSBuild Profiler to analyze where the slow down is. Based on that information, dig into what each task is doing and factor in the things that Chris mentions in his answer.
Is it a C++ project? I had the same problem when I moved my project from Visual Studio 6.0. Turning off the Code Optimization did save a lot of time. It was almost impossible to work with activated Optimization.
It re-evaluates the references on every build. If any of your references are on network drives that could be slowing it up.
Some computers are naturally going to perform builds faster than others.. This is, in part, a function of processor, ram, and HD speeds.
Regarding why you see 7 minute build times there could be any number of reasons. Amount of code in project(s). Number of projects in solution. Amount of post / pre build steps. Speed of network in downloading anything from source control it needs. Number of other processes running on your computers. Amount of RAM and other resources available to perform the builds..
You get the idea.
It is slow to load anything other than a small project. It is slow to quit; it can sometimes take minutes. It can be slow to open new files. The record macro feature used to be useful. It is now so slow to start up it's almost always quicker to do it manually!
More info would be helpful. How big are your solutions? What platform are you on. What 3rd party plugins are you running? What else is running on your pc?
3.2GHz P4 Hyperthreaded, 2GB RAM. Running Outlook, Perforce, IE7, directory browsers. Usually have 1-3 instances of VS running. It's much slower than VC6, say. It seems to take a long time to load projects and close down. I'm interested in if people know reasons why this happens, because of the way VS is written. Is it using .net internally and GC slows it down?
One of the biggest culprits for Visual Studio 2005 slowness is Intellisense. This has been brought up on the MSDN forums again and again and again. What I frequently experience is that Intellisense is working nearly non-stop to "re-index" symbols (or whatever you call it). But developers at Microsoft have not been deaf to the complaints and some outgoing folks there have come up with some workarounds that have helped me and might help you:
Check out this link to get a better understanding of Intellisense:
Intellisense Info
Then check out this link for some macros that I've had a lot of success with:
Intellisense Macros
With those macros, you can turn off intellisense (without renaming any DLLs), restart it, delete the ncb file (which you can do manually, but this is a convenience) and it can give you the status of Intellisense.
it might be that you have a plugin that is misbehaving. Try the safemode switch to see if this improves performance
One of the biggest culprits for Visual Studio 2005 slowness is Intellisense. This has been brought up on the MSDN forums again and again and again. What I frequently experience is that Intellisense is working nearly non-stop to "re-index" symbols [...]
I agree. I use Visual Assist. It is much better. There is no real way to turn "Intellisense" off either. The only way I have found is to rename the DLL so when you restart VS it is not found. This works and makes VS faster.
I tend to agree that VS is a heavyweight. Back in the day I coded in DOS using Boxer text editor and makefiles. Boxer didn't have the heavy intellisense and refactoring features, but it did better in the text editing department, had good syntax highlighting and startup/closing were instantaneous, even on a 486. ...those were the days.
I would say it would be really nice to customize VS to remove all the overhead you're never going to use anyway, but I don't see that happening.
here's ya problem:
3.2GHz P4 Hyperthreaded, 2GB RAM
Hypertheaded means "doesn't actually have two CPU's, but it fakes it". If you have a process with just one thread running, then you get bad performance. It was a good short-term measure, but compared to having two REAL CPU's, it's a slow hack.
I don't think that's the problem at all. The machine is plenty high spec enough to be professional C++ development machine for large projects. I can run Eclipse (which is Java, which is memory hungry and slower than native code) and this is still way faster than VS 2005.
I doubled the amount of RAM from 1GB to 2GB. This helps a lot with linking large applications. We also use Incredibuild to accelerate compilation. But it's the VS app that is slow.
And if you think I'm a grumpy anti-MS zealot, ask yourself why people aren't buying Vista! :)
I'm am seeing mixed results with faster machines. Sure, faster machine, hides the poor performance quality of vs2005 but not all.
Simply taking your obligatory "hello world" C/C++ program, just compile it, (CL /c helloword.cpp),
#include <stdio.h>
#include <windows.h>
int main(char argc, char *argv[])
{
printf("Hello World\n");
return 0;
}
I see 1 seconds compiler under Vc6 and a 6 seconds compile under VS2005.
Using DEPENDS to profile the two, I see 3 areas where the 5 seconds delays and time different are taking place:
~2.5 secs with ADVAPI32.DLL, CryptGetHashParam()
~1.5 secs with OLE2.DLL, StringFromGUID2()
~1.0 secs with C2.DLL, _AbortCompilerPass()
Again, this is just a compile, not a link. The VC8+ compiler executables/dlls are referencing sub-systems like crypto API, the Registry for some transparent reason and it is adding a tremendous amount of overhead to straight and pure compiles.
While a faster machine may hide some of hide slow down, one could only wonder if Microsoft can optimize the compiler by offering options that disables unnecessary overhead references. I understand the better compiler comes with some overhead, but what I see is a 300-500% compile time degradation - thats awful.
Hector Santos, CTO
Santronics Software
This is a purely subjective thing I am afraid.
May it is because of your low end system configuration.
May be VS trying to get updates from the net?
May be you are running too many application in the background.
May be you are trying to open a huge solution.
Recently I've had both Visual Studio 2008 and Visual Studio 2005 on my machine, and I agree that VS2005 is really heavy. They improved upon it in VS2008, although I'm not sure if you'll consider the performance improvements enough.
Could you maybe time some operations and post them so we get an idea what you mean by "slow"? On my machine, I wouldn't call VS 2005 slow, but if you compare it to notepad or my web browser it seems slow. Here's some things that might help people figure out what's going on:
Turn off any features that could affect load time. This includes uninstalling all add-ons and making sure that VS isn't configured to automatically open a project.
Reboot your machine.
Time how long it starts VS 2005 to start, from the time you click the icon until the program starts.
Create a program that you're willing to post here that seems to compile slowly (this might not be possible depending on what it takes to make a slow compile); post the program and how long it takes your computer to build it.
Do you know anyone else with the same kind of machine that has VS 2005 installed? Does it seem slower or faster than yours?
I believe Lord Kelvin said the best thing that can be said about situations like this:
When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge of it is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced it to the stage of science.
Until you give us some measurements to look at, we can't tell you if your machine is genuinely slow or if you are expecting more out of your machine than it can give. Your HT CPU might be the problem; I have roughly equivalent machines at work and at home, but my dual-core work machine runs circles around my single-core home machine when it comes to running VS.
VS 2005 is slower than VS 6 because it is less well optimized for speed. The developers of VS 6 had slower machines than the developers of VS 2005. They made it fast "enough" back then. On a modern machine VS is now "pleasantly fast", where VS 2005 is only just fast enough.
What annoys me is that they decided to scrap VS 6 and start again for VS 2005, when VS 6 was an awesome piece of software that just needed updating.
I noticed above you mentioned you are using perforcet too. Do projects load faster when not in perforce, I am willing to bet that some of the delay you are seeing is related to perforce during load. The latest version of perforce seems a lot slower too.
Change your Solution Platform on "Any CPU" option which is given on the top of Visual Studio then your program build speed will be definitely increased.
here's ya problem:
3.2GHz P4 Hyperthreaded, 2GB RAM
Hypertheaded means "doesn't actually have two CPU's, but it fakes it". If you have a process with just one thread running, then you get bad performance. It was a good short-term measure, but compared to having two REAL CPU's, it's a slow hack.
2GB of RAM would be an issue too, based on what you said you run. If you have a basic 5400RPM disk, then it's going to make it all worse.
I'd recommend, based on what you posted:
A good core2 machine, maybe a quad if you have the budget.
3GB of ram if you are running a 32bit OS, 4+GB if you are running x64. 4GB means you waste 1GB under 32bit.
Get 7200RPM disks, or better. If you can, RAID0 them (stripe) or RAID0+1 (stripe+mirror) if you can get 4 drives (stripe == split content over the two disks, so you can read from both at the same time. stripe+mirror == the safe version of striping, so your code is on TWO disks at all times)
I have a 2.0ghz Core2 (so roughly 3-4x the performance of your P4, if you count 2 CPU's(cores) to be 2x) with 2GB, and the most I can run well is 2 instances of VS.NET 2008. This is normal - nothing wrong with VS.NET, it's just a huge app.
More RAM. More CPU. More Screen. More. More. More :)