Every now and then, I have seen my CPU usage jump up to close to 100% on all cores, which can slow things down somewhat…
This looks really impressive, like I’m working so hard that my machine can’t keep up with my frantic pace. Sadly, this isn’t always the truth!
Looking at Task Manager, shows the culprit to be microsoft.alm.shared.remoting.remotecontainer.dll.
If you are using VS2013 or later, and are not using the Community edition, you may notice some annotations above your methods and properties…
This feature is known as Code Lens, and is one of those things that is really worth getting to know, as it’s a massive time-saver.
Quick digression from the main theme of today’s symposium to tell you why it’s so good…
By default, there are about five or six code lenses, but as I’ve changed my options to show only one, only that one is visible in the picture above. This one allows you to see all references to the item in question. Click on the link and you’ll see something like this…
This can be docked as a window (click the little rectangular icon in the top-right corner of the code lens pop up). If you double-click an item in the list, you are taken to the appropriate line. Jolly useful.
End of digression, back to the point
However, this fab feature comes with a price. The assembly responsible for scanning your code and updating the Code Lens is the one mentioned above, and can use whopping amounts of CPU.
However, as the most (and in my opinion only) useful part of Code Lens is the references, you can tell VS not to bother with the rest, which will avoid the CPU usage. If you write unit tests (I know Yossi, we all should, but let’s be honest, none of us do!), then the unit test one is also very useful, as it shows you how many tests hit that method and how many passed. However, unless you’re really doing TDD properly, it won’t be that much use. Note: Please read the second “possibly useful tip” further down, as that is relevant to unit tests.
Go to Tools -> Options -> Text Editor -> All Languages -> Code Lens and uncheck all of the individual checkboxes. Leave the “Enable CodeLens” checkbox checked, as this will give you the references link…
This should make a big difference to the CPU usage.
Possibly useful extra tip
The other thing that sometimes helps is to have a look in C:\Users\<username>\AppData\Local\Temp\ALM\ShadowCopies\<some_guid> and see how many folders there are. The more there are, the slower Code Lens will be.
You can safely delete them all, and it will slowly replace them for you. I had 5,400 of them, but have seen reports of 190,000! You’ll need to do this every now and then if you find that microsoft.alm.shared.remoting.remotecontainer.dll continues to use CPU.
However, I found that they were replaced almost as quickly as I deleted them, so your mileage may vary.
Possibly useful extra tip the second
Quoted from a StackOverflow answer…
It seems each time you run your tests in Visual Studio, it stores the result of your tests in TestResults folder in the project folder and it was about 800MB in size in my computer.
I just deleted it and clean the project bin and obj folders as well (which I did for several times before and didn’t really work). But removing TestResults folder did the magic.
My guess is that because of the humongous size of the TestResults folder, Visual Studio 2013 cannot load all the results etc. quickly and that’s why it was taking years to show me Code Lens feature. So delete that folder time to time for better performance.
Here are some results about TestResults folder after I googled it:
- How to: Deploy Files for Tests:Â http://msdn.microsoft.com/en-us/library/ms182475.aspx
- How to preserve the test results directory?:http://blogs.msdn.com/b/aseemb/archive/2013/02/23/how-to-preserve-the-test-results-directory.aspx
- How to delete Test Results folder:http://blogs.msdn.com/b/ploeh/archive/2006/07/13/cleaningawaythetestresultsfolder.aspx
UPDATE
Even if those methods above may work for you, I realized that they actually fixed this issue since Visual Studio 2013 Update 2. So instead, please update and install it.
From the comments on that answer, it seems that even with VS2013 Update 3 installed someone was suffering from the same problem. Deleting test results + obj + bin solved it. Furthermore, someone else commented that he had to remove test results in VS2013 Update 4, so the Update 2 didn’t fix it.
He also mentioned that circular references also prevents code lens references from working.
Be First to Comment