I've been working on an intermediate-sized project in Visual Studio 2013 in C#/WPF. It relies on the Kinect SDK, and there are a good number of objects implemented in the code. When I run the debug cycle the first time (using the release configuration), execution is pretty speedy. On subsequent runs, the execution (especially of the code to connect to the... erm... Kinect) slows down significantly. I was wondering what could cause this, and what I could do to diagnose it. Are there any benchmarks in Visual Studio or things I could do to make the slowdown go away?
Related
I am using Visual Studio Professional 2017 15.2 (26430.14) and my CPU is between 40-60% on my PC everytime I am writing code. It is really anying since it creates a lag for every character input. Sometimes several seconds. I should state that my PC is not of the most performant kind, but I do have SSD and 16 GB of RAM.
I have Resharper and NCrunch installed, but I have tried to disabled them, but without any result.
The process that spikes the CPU is:
devenv.exe
And also sometimes:
ServiceHub.RoslynCodeAnalysisService32.exe
The cause of my problem was something called "CodeLens" (https://msdn.microsoft.com/library/dn269218.aspx). This is some kind of realtime analysis of the code giving you references and usage direct within the code. I guess it was a little bit to hard on my weak machine.
When I turned this feature off my lag disappeared instantly. You can turn it off here:
Options
Text Editor
All Languages
CodeLens
I was happily debugging some C# code in Visual Studio 2015 when I started to notice that a VsHub related process (Microsoft.VsHub.HttpHost64.exe) was going bananas with memory consumption and slowing my whole system.
and even after I close the application I was debugging and Visual Studio it still was consuming memory.
This keeps happening and makes debugging with Visual Studio a little bit frustrating... when this stuff is consuming more than twice the memory your own program is allocating.
Anyone having the same issue and solve it (without deleting/renaming the executable)?
Any thoughts?
we are using Visual Studio 2013 with latest updates installed. Our solution(s) contains about 20 to 30 C# library and asp.net projects. We also have some extensions installed such as Resharper, VSCommands and NCrunch (all latest versions as well).
After working a couple of minutes on a solution the memory of Visual studio increases to more than 2GB of RAM. The IDE is becoming very unresponsive.
Usually i have to close a solution after working with it after 1 or 2 hours.
When not closing VS myself the RAM usage goes up to 3GB+ and VS crashes (probably because VS is still a 32bit application)
How can i identify what causes Visual Studio to use so much memory?
Thanks
(I realized that ncrunch is also using a lot of RAM when executing our tests. Therefor i have disabled it. It takes a couple of minutes longer for VS to use so much ram when ncrunch is disabled but the problem remains)
Ran into a similar scenario on my end. But mine was purely resharper.
I had personally used the following things to optimize the performance.
http://confluence.jetbrains.com/display/NETCOM/Ultimate+Guide+to+Speeding+Up+ReSharper+(and+Visual+Studio)
For huge projects, I usually turn off the solution wide analysis for it.
We identified that the latest perforce plugin for visual studio (p4vs: p4vs11_2014.2.93.1619.vsix) was the cause for VS to grow in memory usage.
We downgraded to p4vs11_2013.3.78.1524.vsix. This fixed the problem.
(Also it seems that p4vs11_2014.1.85.4506.vsix is still working)
I am using WinForms, Visual Studio 2013, .Net 4.5
When running my application through the Visual Studio Profiler, it works exactly the way it should and when running it through either Debug or Release mode, I face horrible freezing and repainting issues.
What is the difference between running your application in the Visual Studio Profiler vs. running in through the Release Mode?
Thank you in advance
Finally found the answer here:
Why does my program run way faster when I enable profiling?
When you run your application within Visual Studio, the debugger is attached to it. When you run it using the profiler, the debugger is not attached.
If you press F5 to run your program, even with the Release build, the debugger is still attached.
Since I was running my application through Visual Studio, I was seeing some really strange behavior such as slow repainting, freezing, etc. - I spent days chasing the usual suspects, double buffering, not invoking calls from background threads, missing locks, etc. and it turns out I was chasing a bug that wasn't there on a first place. Hope this saves someone hours or headache.
There is a debate going in our department to virtualize Visual Studio into App-V, Microsofts Application Virtualization. In the back of my mind, I think doing this will cause problems when trying to debug or run other tasks in Visual Studio but I can't put my finger on any one thing to support my argument.
Has anyone had any experience with Visual Studio 2010 running inside App-V?
I am open to the idea if there are no issues but I am afraid that if this is put in place, we will have issues.
What do you think?
Based on the description of App-V here I'd be shocked if the performance was good enough for Visual Studio to be usable. VS is a very processor and IO intensive application. Virtualizing its entire operation over the wire is likely drag performance down to unacceptable levels.
I have seen VS perform acceptably on local VMs running VirtualBox, that might be another option for you if platform standardization is your goal.
I know this is an ancient question, but I found it in a Google search. Just wanted to mention that we've been running Visual Studio 2010 this way for a couple of years, and it's fine. We use it in both a classroom setting and on developer desktops.