I'm using VS2008, in a normal mid-size solution.
Sometimes, debug stepping becomes very slow. A padlock gets rendered on the every file tab for every "step" (F10/F11), and it can take up to two seconds for every step. That makes debugging very annoying and slow. Has anyone seen this problem?
I've noticed in VS 2008 that if you have the 'Show Threads in Source' button selected in the debug toolbar that stepping can be at least 10 times slower.
I've also noticed that if your application takes a long time to start in debug mode that this can be resolved if you simply 'Delete All Breakpoints' under the Debug menu. This solved an annoying problem for me even though I only had a handful of breakpoints set at the time.
Silas
Try turning off the "Enable property evaluation…” setting in Debugger options, it should make debugging much faster (read more: Fix: Make Debugging Faster with Visual Studio):
(source: flickr.com)
Disable Show Threads in Source in Visual Studio. and Close Call Stack Trace Window.
In addition to all issues mentioned above.
A "Disassembly" tab (opened in a background) slows down the debugging by 1-2 sec per step.
(Not sure if it always happens like this).
I had the same issue, especially when debugging apps with many threads.
It was caused by the feature "Show threads in source".
See the following link for details:
Code Project: Show threads in source
Visual Studio Single Step Performance Fixes
After disabling this feature, problem has been fixed.
There are many things that can cause Visual Studio to be slow. Excessive breakpoints and Show Threads in Source are probably the two most common, but you don't care what is most common, you care what is making Visual Studio slow for *you*.
So, if deleting breakpoints and turning off Show Threads in Source doesn't work then you need to profile Visual Studio. That lets you find performance problems that are unique to your situation. An explanation of how to do this (which resolved two separate Visual Studio performance problems) can be found here:
http://randomascii.wordpress.com/2013/03/03/visual-studio-single-step-performance-fixes/
More investigations of performance problems in other people's code are detailed here:
http://randomascii.wordpress.com/category/investigative-reporting/
Accepted answer is hardly relevant or helpful!
These are some possible issues that could make debugging extremely slow:
"Show threads in source" (see screensht). If you have a heavily mutithreaded app you won't be able to debug with this option enabled. What this options does is it tries to show in the same file execution position of other threads if they also execute the same code. So, if you have many threads debugger needs to check for all threads where they are located. If you have many threads this might make each step with debugger extremely slow.
Many conditional or even regular breakpoints. Especially if these are in some inline functions of some header file.
"Show external code" enabled in call stack also makes it slower.
Disable “Show Threads in Source” if it is enabled, and also close the Parallel Stacks Threads, Tasks, and GPU threads windows if it they are open. Those cause the debugger to walk the call stack for every thread in the process.
Yes, Visual Studio is extremely slow at debugging at times. There are a number of additional steps (in addition to turning off the Enable property evaluation" setting) you can take to speed up the process. Essentially, it requires massive amounts of RAM, so performing a few things to free that up will help.
Go into the preferences of Visual Studio. Look for all the options relating to animating menus and so forth. These have a tendency to be intensive at times, while not specific to debugging as you usually aren't opening up menus, it does seem to help.
On the computer itself, if you right-click on my computer. Go to the advanced tab and under performance. If you adjust your computer for best performance it'll speed things up. It gets rid of any nice styles on your computer, but it'll free up some of the memory you are wanting.
Close any unnecessary programs. The more memory you can give Visual Studio the better it is going to behave.
Here's a link to some guidance on Mike Stahl's MSDN blog, with respect to resolving debugger slowdowns
I ran across this because conditional breakpoints in my app's hotspot killed my debug performance. Personal BKM: resolve potential performance issues before you leave for the night, for you may not remember them in the morning.
Another cause of single step slowness is use of Intellitrace (available only in Ultimate). To turn it off, Tools | Options | IntelliTrace. Uncheck Enable IntelliTrace.
The "Show Threads in Source" suggestion did not help.
But I fixed it by enabling Tools:Options:Debugging:General - > "Require source files to exactly match the original version".
Mine was unchecked initially, but after changing it stepping through code in VS2008 is now back to normal speed.
What helped me was disabling Diagnostic Tools.
Tools / Options / Debugging / General / Enable Diagnostic Tools
Visual Studio 2015 (Version 14)
I experienced this problem after enabling ".NET Framework source stepping". Stepping got a lot faster after turning this off. In particular, turning back on "Enable Just My Code" (Options > Debugging > General) removed about half the lag I was experiencing.
The other half was caused by loading more Symbols than I needed (Options > Debugging > Symbols). At one point I needed Symbol locations defined, but I didn't anymore, so I was able to uncheck them all and click "Empty Symbol Cache". If you have _NT_SYMBOL_PATH listed it means you have this environment setting defined, and Visual Studio won't let you uncheck it. You'll need to remove the setting. More about Symbol settings (https://blogs.msdn.microsoft.com/visualstudioalm/2015/01/05/understanding-symbol-files-and-visual-studios-symbol-settings/)
I had the same problem, I deleted all my variable watches and it helped a lot! Because each step during debug, it reloads all watches and it takes time...
Solution : From the Debug menu, choose Windows, then Watch, and click on Watch1, Watch2, Watch3, or Watch4. The menu will appear and right click on them to clear them all.
If you have a virus scanner (with realtime scans enabled), check if C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe* is excluded from the scan.
In my case, debugging became very slow after the companywide rollout of new virus scanner. After a while, we found out that the realtime scan of msvsmon.exe was the culprit.
*modify path as per your installation folder
clear all entries in the watch window.
Related
When placing the curser on a closing bracket in c# for instance, there is a small annoying delay before the opening bracket gets highlighted, and you have to sit and wait before you can use shortcuts such as (ctrl + shift + up/down). It feels like it is intended behaviour for reasons beyond me, so i don't think it is a bug or because my computer is slow (it's not), but it's driving me crazy.
I'm on a freshly installed PC, so i have only testet it in a few programming languages / file formats, and the behaviour only occours in some of them.
The delayed highligh behaviour occurs in .cs (c#), and .css files, but not in .js and .html files, here the code gets highlighed instantaneously exactly like i want it to in .cs files aswell.
I'm using Visual Studio 2015 Community Edition.
I have had this problem as well, since first installing. I can confirm that Update 1 CTP addresses this issue, and the delay is almost gone (maybe 1/8 second now.)
This UI delay was actually called out as a bugfix that was included with the update:
https://support.microsoft.com/en-us/kb/3025135
To the problem that there is a delay highlighting the brackets: In my opinion that has nothing to do with a bug. I think it takes a little while because your code needs to be parsed every time you change something in order to highlight the brackets. When you have many lines of code in one file it is obvious that it takes a little more time than normal.
Here are some tips that may help you:
Click the bracket and press STRG + ´ this will bring you directly to the other bracket. Or you press ALT + ´ and it will mark all your code in between your current brackets. You can look up the shortcuts of Visual Studio in Tools -> Options -> Environment -> Keyboard:
I'd recommend everybody programming in Visual Studio is to change the highlight color of the matching bracket. Have a look at this:
Here you can change all the colors and forms used for specific searchterms. I personally use Visual Assist 2015 to highlight my code (that's why I didn't change anything here). It is way more faster than VS itself and comes with a lot more functions like bracket guidelines who will show you the indent level of your brackets. Have a look, maybe you like it:
Its about 500ms in a newly created console project
500 msec is a magic number in .NET. You can get some insight from the source code for the C# Language Service, accidentally (?) exposed by a Microsoft programmer on github. Most relevant file is probably this one:
internal interface IBraceMatchingService
{
Task<BraceMatchingResult?> GetMatchingBracesAsync(Document document,
int position, CancellationToken cancellationToken = default(CancellationToken));
}
Or in other words, the brace matching service runs as a background task. Such tasks normally run on a thread-pool thread and are subject to scheduling by the threadpool manager. That's where the magic 500 ms number comes into play. The manager attempts to keep the number of executing tp threads down to the number of processor cores available on the machine, the most efficient way to run threads. However, if the existing tp threads take too long to finish their job then the manager assumes that they are bogged down by I/O and allows an extra one to run. It does this once every 500 msec.
So first-order estimate of your problem is that VS has too many active thread-pool threads and they don't complete in a timely manner. Causing the brace matching task to run too late.
Finding out exactly what specific tasks bog it down is technically possible. I can't guarantee success with the Community edition and you'd need a fair amount of insight in how to read thread call stacks to get ahead. Startup another instance of Visual Studio and use Debug > Attach to Process. Pick "devenv.exe" from the list. Let it trundle while it is attempting to find PDB files, then use Debug > Break All.
First place to look is Debug > Windows > Tasks. Pretty unlikely you'll see anything there however, normal is to see none. Next one is Debug > Windows > Threads. You ought to see about 15 active threads back in that window. Hover over their Location column to take a peek at their callstack. Making sense of what you see isn't that simple unfortunately, it will help a lot if you can compare what you see with another machine that does not have this problem.
Since you have this problem on more than one machine, another approach is to look for an environmental factor that they have in common. Things to look for are aggressive anti-malware, a network connection that is too slow or too unreliable, a poorly performing add-in that you like but runs poorly on a VS version it wasn't tested on.
And consider that VS2015 isn't exactly ready for prime-time. Of all the recent VS versions released in the past 18 years, it is probably the least stable. It has a lot of heavy internal changes and there were an unprecedented number of alpha and beta versions with critical bug fixes implemented just a few months ago. Try it again after Update 1 is released.
Seems like this will be fixed in a future Visual Studio update: https://github.com/dotnet/roslyn/issues/1906#issuecomment-145874647
I have not found a definitive solution for your problem.
This was a known bug in the VS2015 review edition.
This links discusses the delay (this link refers to c# btw, not c):
https://connect.microsoft.com/VisualStudio/feedback/details/1033540/braces-are-not-highlighted-correctly-in-c
And there are still similar problems for some VS2015 Community Edition users.
http://www.developerteacher.com/msdn/bracket-matching-highlights-not-working-like-i-had-in-2013-express-4227
Personally, I think you are stuck with a bug and if I were you I'd try the following:
Make sure I had unistalled all previous editions of VS.
Try a repair.
Completely uninstall and reinstall VS2015 if running repair doesn't work
Go back to VS2013 if it drives you cannot stand it, and wait until VS2015 is a bit more ripe on the vine.
One thing I have found with VS, is when it plays up it's painful, it takes so long to install and the worst case was when I ended up uninstalling and downloading everything that was associated with the install. It now works fine. (this was after previewing 2015 and then going back to 2013). You can also try this for VS2015 and also try a new download.
I sometimes will have a look at some previews, but after jumping in with haste too many times with the latest software releases and then repenting with leisure. I am now happy to wait for new releases to be out for a while before upgrading.
Another FYI for you to browse.
This is a link to Visual Studio 2015 RC fixed bugs and known issues. There are quite a few issues and hacks suggested. (not specific to your problem, but still there a few months ago.).
I am assuming you know how to play around with the settings. I've added the obvious, in case it's been overlooked.
I have added this screen shot from VS2013 settings.
Make sure you have automatic delimeter highlighting checked.
Sorry I could not be of more help.
I'm using Visual Studio 2013 with ReSharper 9 on a quite strong computer (16GB RAM, Core i7 CPU, SSD, etc.). Still I experience heavy delays and laggings during typing for example in a C# or Razor source file.
I've noticed that every time I hit a key, the processing immediately starts, and context actions, offering rename refactorings, autocompetion immediatley shows up in the editor. It would make sense to delay these stuff for example so that all of this processing would start only when I finish typing and have some amount of quite milliseconds.
I've browsed through the settings for the third time now, but could not find anything related. Is there anything like this? If yes, where? If no, what else could I do to overcome this lagging? It's really annoying and I don't quite understand it. I can't beleive that such a computer is still not enough.
Disable Bing Developer Assistant extension if you have it by going to 'Tools -> Extension And Updates'.
Disable the Microsoft Git Provider Plugin by going to 'Tools -> Source Control -> Then setting the Plug-In ComboBox to NONE.'
The above has helped me and has improved performance on my PC. Hopefully it will help you too.
You shouldn't be seeing a lag while typing. I'd suggest disabling other extensions to see if there's a clash - something that ReSharper doesn't like being installed at the same time. Alternatively (or better yet, as well) you can profile Visual Studio to see what's going wrong. Go to ReSharper → Help → Profile Visual Studio, and ReSharper will download the profiler, attach to Visual Studio and start to gather info. Once you've demonstrated the problem, click "Get snapshot", and ReSharper will save the snapshot and add it to the dialog as an attachment. You can then describe what you were doing and submit the snapshot and description to the dev team.
I'd also suggest downloading the latest build - the 9.2 EAP has just started, and contains a number of fixes that might help performance under certain circumstances.
Also, what are you typing in - what language, what size file?
I'm running Visual Studio 2013 Update 4 and have been seeing high CPU usages and noticeable delay on simple UI menu navigation and basic text editing.
Using ProcessExplorer I took a screenshot which shows one thread is doing a lot of CPU in something called IsAssertEtwEnabled:
The screenshot was captured randomly scrolling up and down in the Extensions and Updates window.
Any ideas how to speed up performance?
And yes I'm running several plugins, but I'd prefer to keep them, or at least find a way to isolate which one is causing this.
And I've reviewed a similar issue (VS2013 Update 3 incredibly slow - devenv.exe!!IsAssertEtwEnabled guilty thread), but I don't have anything from DevExpress installed.
Looks like this is caused by browserLink going rogue (or it was for me anyway)
You can disable it next time the issue occurs:
For me when I disabled it I immediately got my CPU back. I personally was linking to chrome though I'm not sure it makes a difference.
I guess if you use it hopefully it will be fixed in a new version...
Try to disable extensions one by one.
I fixed the issue by clearing ReSharper cache (VS 2015 CE).
ReSharper > Options > General > Clear Caches > Restart Visual Studio
#Sergii noticed that it's possible to delete the cache data directly in file system (%localappdata%\JetBrains\Transient).
I've got a relatively small project written in ASP.NET MVC3. After working a while, Visual Studio 2010 becomes very slow in Razor views (other file types work fine). With "slow" I mean "every keystroke takes around 1 second to register". It doesn't matter what that keystroke was - typing a single letter is as slow as pasting a screenful of markup. During this slowdown VS2010 consumes 1 CPU core to 100%. After I restart VS2010, everything goes smoothly again for a small while. This happens in any and all Razor views.
My PC isn't the best, but it should be enough: Core 2 Duo 6700, 4GB of RAM (currently only 75% filled with VS2010 being slow and all, so it's not a RAM shortage), Windows 7 x64.
The project is close to an end, and I remember that for most time there were no problems. This has started only recently, although I cannot imagine what could have caused it.
Does anyone have any ideas about what could be wrong and what could be done to fix it?
It is plugins - TFS/AnkvSVN and ReSharper have all caused problems for me.
Turn them off one by one, to discern which one (if only one) is causing you grief.
When you find the culprit, make sure you keep up on any patches with it.
In extreme cases, turn if off if you have a long development session and don't need it the whole time (SVN for instance could be turned on when you are ready to do commits and check ins, etc.)
The issue is resolved for me, by installing the Mvc Html5 Templates.
After the installation, I picked XHTML5 and then back HTML5 from the "Target schema" combo box. After that, the paste was instant!
Edit: I uninstalled "Mvc Html5 Templates" and the issue didn't reappear. Perhaps it has something to do with the "HTML 5 Intellisense"
Have you installed sp 1 it fixed some performance related issues when loading IntelliSense for markup
Run the Resource Monitor (CTRL+SHIFT+ESC, click Performance tab then Resource Monitor button at the bottom). Pay special attention to disk I/O and perhaps CPU usage.
Sort disk I/O by Total B/Sec descending. As you type, see if it can identify a process which is causing the issue. Hopefully it's a virus scanner or some other famous performance destroyer and not the Visual Studio process itself, which wouldn't be very helpful.
Have you tried opening the same project on a different machine? This will give you an idea whether issue is in the project or VS install. Quite obvious, but is there anything in the event viewer. Are you connected to a domain while this is happening?
Well, for me the problem has turned out to be anti virus - we use (or are made to suffer) Sunbelt Vipre on our workstations and as soon as I switch off active protection (so that's basically disabling AV completely) all of a sudden all the performance issues in all windows are gone.
Sorry for adding another answer, but there seem to be lots of different causes, so - lets list all possible fixes here.
I tried disabling ReSharper and other addons - did not work. What did work - is reapplying the SP1 again.
PS. Weird, I know. Don't ask, no idea... My guess is - VS was "repairing" itself silently at some point and restored some non-SP1 components.
PPS. You might also want to try disabling "Productivity Power Tools" addon. If you have ReSharper installed - almost all the PPT features are already there, in ReSharper.
PPPS. I have a blog post with several performance tips for Visual Studio & ReSharper, might come handy..
Have you tried Cleaning the solution?
In my case, high CPU usage started out of nowhere (WPF project). Restarts of Visual Studio didn't help, neither disabling/uninstalling addons. But Cleaning the solution did help!
I was experiencing a very similar issue on a large cshtml file in VS 2015 and was solved for me by turning off all of the automatic formatting options in Options > Text Editor > C# > Formatting > General:
I then use the "Control+K,D" key combination to format the page once I have finished making the necessary code changes.
When using Visual Studio I often encounter situations when the IDE freezes while performing some operation. For instance, this frequently happens when I move next statement pointer (yellow arrow) during the debug session, when I unintentionally press F1, step into some low-level function that has multiple instantiations in the binary code etc.
In these situations Visual Studio notification balloon shows up in the tray with the following text:
Microsoft Visual Studio is Busy
Microsoft Visual Studio is waiting for an internal operation to complete. If you regularly encounter this delay during normal usage, please report this problem to Microsoft.
Often the delay is so long that it is faster to kill the Visual Studio process, start it over again, restart debugging session (or whatever else I was doing) and avoid doing an operation that has caused such a delay. However, this still takes too much time. I would like to have a way to stop/cancel the operation that is taking so much time. For instance, in Total Commander this is possible by pressing Esc during such an operation.
Is something like this possible with Visual Studio? Any plugins that allow doing it? Any other way to circumvent the problem?
P.S. Sorry for the lenghty description, but I wanted to explain the actual problem (not ask if certain solution is possible), so that people can think of ways to solve the problem.
P.P.S. Both 2008 and 2010 suffer from this problem.
If you're debugging, try hitting SHIFT-F5. This should stop the debugger, though probably not immediately, faster than what you've described. The program will process the keyboard a lot faster than trying to click menus with the mouse.
If you're building, try hitting CTRL-Break. Again, it may take a few seconds, but it usually comes around.
I've had the problem you mentioned a few years ago, but I can't remember what I ultimately did to fix it.
There may be many different causes of this issue, but for me apparently what was slowing it down was trying to load symbols from symbol servers. I unchecked the Symbol file (.pdb) locations in the Debugging\Symbols options and the problem went away entirely.
run iisreset may solve your problemstart >> iisreset.exe