Roslyn: VS 2015 memory usage and perf after some hours of use

[davidroth]

Hi guys,

I am currently working on a relatively decent solution and I am having problems with high memory usage of VS2015 after some time of usage.

I usually have to restart VS some times a day, because memory usage goes up to > 2 GB and the IDE becomes sluggish.

When opening the solution and building it the first time, VS usually consumes about 750MB.
After some hours I usually have > 1.8 GB and the IDE gets slower and slower.

I have also noticed, that when using VS on multiple desktops (ex. undocking a code window on the 2nd screen), memory consumption increases even faster and the IDE becomes laggy in a relative short amount of time.

Are there any known issues regarding increasing memory consumption of VS2015? Or if not, whats the best way to debug this and provide you with some information to improve this? I could use a memory profiler and check which objects are alive if this is helpful for you?

Edit: I am not using resharper. I am using coderush for roslyn on one machine, however the issue remains when uninstalling coderush, so it's not related to it.

[axel-habermaier]

I also have to restart VS from time to time in order to get it fast again. I have Resharper installed, though, they're a known source for sluggishness. So I'm not sure whether it actually is Microsoft's fault. Do you use Resharper as well?

All in all, VS2012 was the fastest VS I've ever used for C# development. VS2015 is almost as bad as the horrible VS2010 performance-wise. I do realize that Roslyn was a huge change for VS and that it initially might sacrifice some performance now to get VS ready for the future (like the switch to WPF was with VS2010). But I really hope that VSnext will focus on performance again like they did with VS2012...

[davidroth]

@axel-habermaier No, i don't use Resharper. I use coderush for roslyn on one machine, however the issue remains when uninstalling coderush, so it's not related to it.
Yes, I also hope that perf will be improved in upcoming updates. Roslyn is great, but perf was better in VS2013 (especially due to the memory leaks described in this issue).

[ViIvanov]

Do you use a CodeLens? I have the same problems with it in the big (60-70 projects) solution.

[davidroth]

I already disabled CodeLens. Performance with CodeLens enabled is worse though.

[asvishnyakov]

As @axel-habermaier says, Visual Studio require more memory at last versions. But I have no problems with it when I work with small projects. VS may use up to 1 GB of memory, but it acceptable price for convenience: I use a lot of features (like WPF designer or CodeLenses) and extensions (like ReSharper) which use a lot of memory. But when I twice rebuild Roslyn solution, VS consumes up to 2 GB of memory, that is a limit for 32-bit process. So, it may periodically freeze until I force gc (Ctrl+F12 twice). Memory profiling + move to 64-bit processes as soon as possible would be the best solution. Building VS with /LARGEADDRESSAWARE may be temporary solution.

[kuhlenh]

@davkean Can you take a look at this, particularly the possible issue around undocking code windows.

[davidroth]

@davkean

There is definitely something wrong when working with undocked code windows or with multiple windows in a horizontal/vertical split view. (Update1 installed)

VS becomes slower and slower, and memory usage increases.
I have also noticed, that once closing all windows after working in multi window mode for some time, VS seems to run "amok". I constantly have 15-20% CPU usage on a 4K I7 4790K. Furthermore memory usage increases and decreases between 1400MB up to 2000MB, and it doesn't stop.

I took these 2 screenshots, while VS was just opened (with no code windows, samples taken within a 1 minute range ).
When it hits the 2GB bar, GC runs and it jumps back to ~ 1400MB. It then constantly increases up to 2GB.

[davkean]

@davidroth I cannot repro this - I'm constantly using three screens of undocked windows, so it doesn't appear to be a general issue, it might be related to what tools windows or projects you have opened.

Does this occur with all projects? Does it occur when projects are closed?

Can you Send A Frown (Report a Problem) if you are using Update 1 and include "davkean" in the description of the issue, make sure you do this from another instance of VS and click Start Recording when it's at its worse:
.

[davidroth]

@davkean I have sent you a feedback with the recording. Although I just recorded once i noticed that memory started to increase up to 2.2 GB while doing nothing. Is this enough?
You should get a heap dump from this right?
Or do I have to record my whole VS session from the beginning?

To answer your other questions:

• _Does it occur with all projects:_ Cannot say, because atm I am constantly working on this large sized project, without much other side work.
• _Does it occur when projects are closed?_: I guess by that you mean if memory and cpu usage is still high after i closed the solution without closing VS? => Yes definitely. I just closed my solution, and VS is still at 20% without any project/solution open, and memory is constantly going up and down between 1.8 and 2.5 GB. After some minutes it has stopped using cpu, but memory stopped at 1.96 GB.

[davidroth]

@davkean

Here is a screenshot from some basic memory monitoring with dotMemory:

As you can see, there are three major collections/allocation phases within 20s timeframe. Memory ranges between 1.4 - 1.9 GB in this sample. (Solution opened, no windows opened, not working with VS)

In the above screenshot you can see the top allocated managed objects.

I took this after about an hour of work. However this time I did not undock any windows. So my previous assertion about this being an undocking issue may be invalid. However working with multiple windows certainly does accelerate the issue I am describing here.

[jedidja]

We have exactly the same problem. Even after closing a project, VS CPU usage will continue to be high and memory usage often climbs to 2GB. It's bad enough that this happens while working on a solution when it's open but unexplainable that it happens after closing it.

[Drauka]

To further build the case for some investigation into this issue, I would add that we have the same issue in our dev team. Memory consumption increases to over 2.5Gb causing visual studio to become unresponsive to the point where the only option is to restart.

[WayneEllery]

We are having the same issue with our Dev team. Our solution is very big. It has 46 projects. I've also installed Update 2 RC and it still has not fixed the issue. We are using Resharper and CodeLens. When first opening the solution it is about 1Gb and then memory increases and after 4 hours or so it goes over 2GB and then Visual Studio becomes unresponsive.

[jmarolf]

Out of curiosity, how many of those reporting problems on this thread are using resharper?

[jedidja]

I'm not running ReSharper or any other similar extension and there are a couple others on our team with the same issue. We _also_ have people with ReSharper installed who experience the same issue.

[jmarolf]

Thanks @jedidja, good to narrow things down. For everyone on this thread that has this happen to them, it would be greatly appreciated if you clicked Send A Frown (Report a Problem) as per @davkean 's instructions

[jedidja]

@jmarolf Ok, submitted. We have about 20 projects in our solution and are running Community Edition. We've tried 2015 Update 2 RC and still see the same problem. I'd be happy to do a screen-sharing session with anyone on the team if that would help.

[jedidja]

Also, the 30-35% CPU usage happens regardless of machine. It's the same on both my desktop (i5-3570K 3.4Ghz) and also on my 2015 Macbook Pro (i7 2.5 Ghz) under Parallels.

[asvishnyakov]

@jmarolf I had this issue both in clear Visual Studio and with ReSharper

[davidroth]

I have updated to VS2015 Update 2 today, and now I am getting this new message bar when the memory consumption is over about 1.5 GB:

However, my overall system memory consumption looks like this:

@davkean Have you been able to reproduce this issue in your labs or do you need additional reports?

[davkean]

+@heejaechang do you know what's going on here? Are we fragmented?

[DanielRowe1]

Update 2 has make VS just about unusable for our large project:

Description: The application requested process termination through System.Environment.FailFast(string message).
Message: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at Microsoft.CodeAnalysis.Diagnostics.AnalysisState.<>c.b__16_2()
at Roslyn.Utilities.ObjectPool1.CreateInstance() at Roslyn.Utilities.ObjectPool1.AllocateSlow()
at Roslyn.Utilities.ObjectPool1.Allocate() at Microsoft.CodeAnalysis.Diagnostics.AnalysisState.PerAnalyzerState.OnCompilationEventGenerated(CompilationEvent compilationEvent, AnalyzerActionCounts actionCounts) at Microsoft.CodeAnalysis.Diagnostics.AnalysisState.OnCompilationEventsGenerated_NoLock(ImmutableArray1 compilationEvents, SyntaxTree filterTreeOpt, AnalyzerDriver driver, CancellationToken cancellationToken)
at Microsoft.CodeAnalysis.Diagnostics.AnalysisState.GenerateSimulatedCompilationSourceEvents(SyntaxTree tree, Compilation compilation, Func4 getCachedSemanticModel, AnalyzerDriver driver, CancellationToken cancellationToken) at Microsoft.CodeAnalysis.Diagnostics.AnalysisState.<GenerateSimulatedCompilationEventsAsync>d__18.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.CodeAnalysis.Diagnostics.CompilationWithAnalyzers.<ComputeAnalyzerDiagnosticsAsync>d__52.MoveNext() Stack: at System.Environment.FailFast(System.String, System.Exception) at Microsoft.CodeAnalysis.FailFast.OnFatalException(System.Exception) at Microsoft.CodeAnalysis.FatalError.Report(System.Exception, System.Action1)
at Microsoft.CodeAnalysis.FatalError.ReportUnlessCanceled(System.Exception)
at Microsoft.CodeAnalysis.Diagnostics.CompilationWithAnalyzers+d__52.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
at Microsoft.CodeAnalysis.Diagnostics.CompilationWithAnalyzers+d__52.MoveNext()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.InvokeMoveNext(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run()
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef)
at System.Threading.Tasks.Task.FinishContinuations()
at System.Threading.Tasks.Task.FinishStageThree()
at System.Threading.Tasks.Task1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].TrySetResult(System.__Canon) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetResult(System.__Canon)
at Microsoft.CodeAnalysis.Diagnostics.CompilationWithAnalyzers+d__53.MoveNext()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.InvokeMoveNext(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run()
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef)
at System.Threading.Tasks.Task.FinishContinuations()
at System.Threading.Tasks.Task.FinishStageThree()
at System.Threading.Tasks.Task1[[System.Threading.Tasks.VoidTaskResult, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].TrySetResult(System.Threading.Tasks.VoidTaskResult) at System.Threading.Tasks.UnwrapPromise1[[System.Threading.Tasks.VoidTaskResult, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].TrySetFromTask(System.Threading.Tasks.Task, Boolean)
at System.Threading.Tasks.UnwrapPromise1[[System.Threading.Tasks.VoidTaskResult, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Invoke(System.Threading.Tasks.Task) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task.FinishStageThree() at System.Threading.Tasks.Task1[[System.Threading.Tasks.VoidTaskResult, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].TrySetResult(System.Threading.Tasks.VoidTaskResult)
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[[System.Threading.Tasks.VoidTaskResult, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetResult(System.Threading.Tasks.VoidTaskResult) at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[[System.Threading.Tasks.VoidTaskResult, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetResult(System.Threading.Tasks.Task1<System.Threading.Tasks.VoidTaskResult>) at Microsoft.CodeAnalysis.Diagnostics.AnalyzerDriver+<>c__DisplayClass36_0+<<Initialize>b__0>d.MoveNext() at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.InvokeMoveNext(System.Object) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task.FinishStageThree() at System.Threading.Tasks.Task1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].TrySetResult(System.__Canon)
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetResult(System.__Canon) at Microsoft.CodeAnalysis.Diagnostics.AnalyzerDriver+<GetAnalyzerActionsAsync>d__83.MoveNext() at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.InvokeMoveNext(System.Object) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task.FinishStageThree() at System.Threading.Tasks.Task1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].TrySetResult(System.__Canon)
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetResult(System.__Canon) at Microsoft.CodeAnalysis.Diagnostics.AnalyzerManager+<GetAnalyzerActionsAsync>d__12.MoveNext() at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.InvokeMoveNext(System.Object) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run() at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef) at System.Threading.Tasks.Task.FinishContinuations() at System.Threading.Tasks.Task.FinishStageThree() at System.Threading.Tasks.Task1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].TrySetResult(System.__Canon)
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetResult(System.__Canon)
at Microsoft.CodeAnalysis.Diagnostics.AnalyzerManager+d__8.MoveNext()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.InvokeMoveNext(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run()
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(System.Action, Boolean, System.Threading.Tasks.Task ByRef)
at System.Threading.Tasks.Task.FinishContinuations()
at System.Threading.Tasks.Task.FinishStageThree()
at System.Threading.Tasks.Task.FinishStageTwo()
at System.Threading.Tasks.Task.Finish(Boolean)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef)
at System.Threading.Tasks.Task.ExecuteEntry(Boolean)
at System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

[awbushnell]

@davkean I was just working back and forth with Marc Paine from the debugger team as I was seeing crashes consistently in our large solution when debugging. We have tracked it to high memory usage in both Rosalyn and the debugger, see the problem report here:

https://connect.microsoft.com/VisualStudio/feedback/details/2524533/crash-when-debugging

The size of our solution is 246 projects, which are native C++/Managed C++ and C#. Anyway, another vote, if you will regarding this memory issue... I am on Visual Studio 2015 Update 2.

[AndrewGretton]

We're experiencing this issue too (gradual memory creep over process lifetime that often results in a crash). We have:

• 20 developers (most resharper users, some not)
• VS2015 Professional Update 2
• Around 80 projects, 1m LOC C#, 500k LOC JS

Removing our Code Analysis rulesets has helped the most to reduce memory usage (but now we have no Code Analysis :-1: )

VS Update 2 fixed issue #7784, which greatly reduced occurrences of runaway RAM usage, but we still experience excessive memory creep over time.

Our event logs are similar to @DanielRowe1 - always an OutOfMemoryException in a Roslyn stack trace.

[davkean]

tag @KevinH-MS @heejaechang @ManishJayaswal

[davkean]

Sorry @mavasani

[ManishJayaswal]

@srivatsn

[mavasani]

@DanielRowe1 The issue you mentioned is a dupe of https://github.com/dotnet/roslyn/issues/10365, for which there is an open PR for the fix. Meanwhile, you can try to avoid this by using the workaround mentioned in https://github.com/dotnet/roslyn/issues/10365#issuecomment-207107438, which avoided the OOM.

[mavasani]

@AndrewGretton you probably want to try the workaround as well.

[improwise]

Visual Studio 2015 is probably the worst Visual Studio ever. It is so bad that we have it listed as the biggest threat to our current software project, far above stuff like lack of resources and money. Our GUI developers are threatening to quit if we don't switch to AngularJS instead. We've tried EVERYTHING but no luck. Microsoft really need to get their act together here.

[mavasani]

@improwise Can you please share a memory dump so we can investigate the issues?

[morrisjoe]

@improwise , Is it possible to connect with you over email or a phone call to understand your issues deeper. I work for Microsoft and have helped customers solve problems related to VS crashes/performance. My email is [email protected]. Please, let us connect off-line and I can help you.

[morrisjoe]

@DanielRowe1 @davidroth @AndrewGretton @axel-habermaier , I would like to connect with you folks as well to dig deeper and understand issues. My email is [email protected]. Please, let us connect off-line and I can help you.

[marcells]

@DanielRowe1 @davidroth @AndrewGretton @axel-habermaier @morrisjoe

We had that "Low memory" problem, the crashes and the high CPU load, too. It disappeared, when we switched off the full solution analysis in Visual Studio. It now has almost the same speed as VS 2013.

Options -> Text Editor -> C# -> Advanced -> Enable full solution analysis

I've made a blog entry with all of our performance tweaks, if you're interested in.
https://mspi.es/blog/5-Performance-Tweaks-for-Visual-Studio-2015-and-large-solutions

[morrisjoe]

@marcells Indeed the 1st workaround suggested in your blog, we are planning to make that (Disable full solution analysis) the default in a micro update that we are planning to do to VS2015 Update2 in the coming days.

[davidroth]

Disabling full solution analysis does not help a lot.
Another observation: Switching between git branches with lots of changes shows the same issue at my machine, with much faster memory increase.
Just had to review several branches and VS grew from 600MB up to 2.1 GB in just ~10 minutes.
This is probably because VS reloads/re-analyzes the solution when switching branches wich lots of changes.

[DanielRowe1]

We have disable full solution analysis and code lens and it has helped but we still get OOM just not as often.

Our solution has 170 projects or so and approx 2.2million lines of code. VS2015 is just so slow.

It there going to be a update we can install to fix these leaks?

[heejaechang]

related issue - https://github.com/dotnet/roslyn/issues/10365

[awbushnell]

FYI, I worked with @morrisjoe off-line and tried private fix and it seemed to help and am ok with shipping it.

[morrisjoe]

That's good news @awbushnell . If others who have 100's of .NET projects in their solution and want to try the private fix that will being relief to mem usage and CPU utilization when doing full solution analysis with lots of analyzers involved, please let me know and I can work with you off-line for you to try out the private fix. Once I get more confirmation that it is indeed good, then I can work towards making it available as public release with VS2013 Update3.

[davkean]

By VS 2013, I think you mean VS 2015.

[davidroth]

Is this private fix somewhere on GitHub or is it too private? :D

Our solution has about 40 projects, would like to try the fix.

[jmarolf]

You can get the vsix here I'm working on making getting this stuff simpler so you can easily try out builds at your discretion. Usual caveats apply, these are nightly builds, there may be issues.

[heejaechang]

@jmarolf can people use roslyn insider feed "https://www.myget.org/F/roslyn-master-nightly/vsix/" to get latest nightly build if they want to live at the edge?

[jmarolf]

@heejaechang they can, though there have been some mef composition failures that I wanted to fix before people jumped in with both feet.

[ilmax]

@jmarolf how can we restore to the official vsix in case of problems?

[jmarolf]

@ilmax yes, uninstall the extension and remove the vsix gallery.

[ilmax]

@jmarolf thank you, just to double check, this vsix applies to VS 2015 update 2 right?

[jmarolf]

@ilmax right, it will only work on Update 2. I don't think I added any install restrictions, so it may allow you to install it on Update 1 or RTM, but it won't work (or if anything works its by accident).

[SamJongenelen]

Same here, I'd like to try. Otherwise, in what timeframe will this be released (or available in a hotfix?)

[jmarolf]

@SamJongenelen you can grab the VSIX with the fixes here. If you have package load failures, run devenv /updateconfiguration from and admin command prompt to get back in a good state

[SamJongenelen]

@jmarolf Thanks, will give it a try today. Left VS open with ~30 .csprojects over the weekend and it now grows 30 Mb RAM for every build :)

[heejaechang]

@SamJongenelen just to make sure it is not GC thing, can you do shift+alt+ctrl+F12 twice to force VS to do full GC and see whether that 30MB still left in memory?

if it does, can we get dump before and after that 30MB increase right after shift+alt+ctrl+F12, F12?

[SamJongenelen]

@heejaechang I would like to, but since I installed https://www.myget.org/F/roslyn-master-nightly/vsix/eb2680f2-4e63-44a8-adf6-2e667d9f689c-1.3.0.60520.vsix the memory usage isn't growing after build anymore! If or when it happens i will record it

[phil-scott-78]

@morrisjoe - would it be possible to make some of these options of disabling these tools available per solution? We have one legacy solution that simply brings VS to it's knees with codelens and full solution analysis enabled. We use it maybe 5% of our development time but most of my team has turned those tools off across the board. I've taken to creating an entire new hive of VS that I launch just for that project which seems to be the "best" approach in terms of keeping VS usable for this one project for me, but a tough one to remember to do for the rest of my team.

[Giorgio-Reco]

I just installed the patch that has been released today (KB3151378) that disables the 'Full solution analysis' by default, which didn't really solve my CPU usage problem I have with VS ever since update 2, even with already disabled 'full solution analysis'.
I also have SonarLint installed on a VS 2015 Enterprise Update 2 with 72 projects in the solution.
When I just launched VS with the solution open, after some seconds, CPU usage drops to a likable 1-3%, which is normal.
But after I executed a build of the full solution (so AFTER the build), CPU usage stays, forever, at 35-50% without even doing anything in VS. I disabled all suspects like SonarLint and Codelens and restarted VS (even rebooted my laptop once), but still the same behaviour : after a build 35-50% CPU usage!
The strangest thing is that when I open a dialog, like for example the Tools --> Extensions and updates... dialog, CPU usage drops to 0-1%...until I close that dialog again and return to the code window....
Any ideas?

[heejaechang]

@Giorgio-Reco

can you send us frown? we need etl to see what is going on.

see this comment to see how you can send us one.
https://github.com/dotnet/roslyn/issues/7082#issuecomment-169145851

but instead of cc: davkean, put cc: hechang.

also, instead of crash, select "something seems to slow."

more info here.
https://msdn.microsoft.com/en-us/library/mt280277.aspx

thank you.

[Giorgio-Reco]

Hi,

I found similar reports already filed, but I'll send the frown anyway.

[cid:40f44932-9566-4b2c-afed-33b7ad470c06]

Thank you very much.

Giorgio Migliaccio

---

Van: Heejae Chang [email protected]
Verzonden: dinsdag 24 mei 2016 16:36:53
Aan: dotnet/roslyn
CC: Giorgio Migliaccio; Mention
Onderwerp: Re: [dotnet/roslyn] VS 2015 memory usage and perf after some hours of use (#7082)

@Giorgio-Recohttps://github.com/Giorgio-Reco

can you send us frown? we need etl to see what is going on.

see this comment to see how you can send us one.

7082 (comment)https://github.com/dotnet/roslyn/issues/7082#issuecomment-169145851

but instead of cc: davkean, put cc: hechang.

thank you.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/dotnet/roslyn/issues/7082#issuecomment-221291273

[Giorgio-Reco]

Is there any progress on this issue? I'm convinced many developers all around the world are experiencing HUGE problems due to this issue! This causes a loss of about 30-45 minutes of work EVERY DAY. And every developer I know, in my company, and in other companies, working with this version of VS are experiencing it!
Worldwide this is costing millions if not billions of dollars, so please fix this asap!
One colleague even tried downgrading by uninstalling service pack 2, but his VS installation was left corrupted and he needed to reinstall his complete machinen taking him more than 1 full work day!
There doesn't seem to be any easy way out of this, unless this is fixed in a new patch.

[TASimpson]

@davidroth I am experiencing the same issue of

and then my VS2015 will become unresponsive shortly after. Did you ever find a fix for your problem??

[davidroth]

@TASimpson

I could mitigate the problem by uninstalling all third party analyzers (e.x. no more CodeRush4Roslyn, no more Refactoring Essentials etc.). More analyzers == more memory :(

I also noticed that the following events seem to trigger this bug:

• Switching git branches - probably because of lots of solution changes and reloading of projects projects etc.
• Refactoring: When I work on some bigger refactoring task which takes some time, especially when this results in "broken" code which is around for some time during the refactoring work.

VS usually has 600-1000 MB when everything is ok. If it grows above 1.4 GB I just restart VS before it gets too slow (I have to do this several times a day).

I also tried the patch which was linked here. Had to uninstall it, and completely reinstall VS, because of some weird bugs, but I cannot remember the exact problem. Have not tried it again since then though. Hope Update 3 will be available soon.

[heejaechang]

@jmarolf is that possible to have roslyninsider.vsix with closed side vsix as well so that they can try the fix?

@Giorgio-Reco can you share the project that having the issue so that we can try it out to see what is actually causing the problem? we addressed one that we know but there could be issues that we don't know about.

by the way, have you tried turning off full solution analysis? is that not resolved issue in your case?

[heejaechang]

@davidroth I think your issue should be addressed by our fix that is scheduled to be released in update 3.

[heejaechang]

@TASimpson have you tried turning off full solution analysis? does your problem still happen even after turning off full solution analysis?

if it does, then, it could be an issue we don't know about. can you provide some kind of repro so that we can track it down root cause?

[TASimpson]

@heejaechang full solution analysis is off and yes, it still does. I have had to restart VS at least 7 or 8 times today.

[Giorgio-Reco]

@heejaechang full solution analysis is off and has been off for a while. Didn't really help that much.
I do have to say we have the SonarLint analyzer installed, and a ruleset for almost every of our 72 projects in the solution.
What I do experience is that the editor very regularly freezes for several (up to 10) seconds when just typing text, and after that i saw the Codelens information got updated. But disabling CodeLens, and even SonarLint, didn't really help either.

[paul1956]

Is there a plan to allow Code Fixes and Analyzers to run as 64 bit code under Visual Studio. No matter what I have tried I can't get some code fixes to work on more than a few 100 fixes in a large solution without running out of memory, I get the low memory warning just seconds before VS runs out and my CodeFix fails.

[heejaechang]

@paul1956 moving VS to 64bit is not something I can say. probably way upper management would decide those. but I am currently working on moving analyzers part out of proc. initially it will be 32bit out of proc process, but eventually will have 64bit host as well. (since some analyzers are made to run only in x86)

but that is just analysis part, code fix part for now will still run in VS due to dependency code fix can have to its host (in this case VS).

so I can't say our OOP work definitely will fix your issue or not. but I believe it will improve experience a bit.

eventually, we hope we can move code fix side (which doesnt depends on host) to out of proc as well.

[heejaechang]

@Giorgio-Reco @TASimpson if full solution analysis is off and if it still has perf problem, then it probably not something we know of or addressed in update 3.

we need some way to repro the issue to figure out what went wrong. can we work with you guys to dig into the issue?

tagging @morrisjoe

[davidroth]

@heejaechang
You mentioned that you are moving analyzers out of proc.
=> Does that mean that analyzers will run in a separate process (Like the compiler-server "VBCSCompiler.exe") and communicate via some protocol with VS?

Wouldnt that mean that we then have 3 separate processes (VS itself, "VBCSCompiler" and "VS-Analyzer (new)") which all have their distinct copies of the solution in memory? Doesn`t that triple the overall system memory consumption? I though one of the benefits of roslyn with its immutable trees, is free sharing of all those information across threads? Out-Of-Proc sounds like a "ReSharper" like solution for me ...

[paul1956]

@davidroth to me having 3 copies in a system with 16+ gigabytes of memory is a who cares compared everything sharing ~3 gigabytes. Each proc gets it own 3+ gig or its own 64 bit address space.

[jmarolf]

@davidroth why would we choose to implement it as three separate processes? I we move it out of proc, VS will not _also_ hold all of the workspace state in proc. HeeJae is currently designing and implementing this so nothing is set, but a reasonable design would be to add this functionality to the compiler server so you have one 64 bit process that is allowed to grow, while the VS side of things only needs allocate a little to handle serialization with the compiler server.

[davidroth]

@jmarolf Thanks for the clarification - this sounds a lot like "OmniSharp" for VisualStudio ;)

[Giorgio-Reco]

@heejaechang We gladly like to work with you in getting this issue solved since it's really getting in our way in our day-to-day job and meeting targets.
Just let us know what we can do to get you all necessary information. If it comes down to sharing our code, we must be sure this can be done in a safe and confidential manner.
One small thing: a former colleague of mine tried opening their problematic solution in VS 15 Preview 2 and he told me that memory consumption was down quite a bit, like only 450MB instead of 1GB and performance was also far better than 2015 Update 2.
A (current) colleague of mine tried uninstalling Update 2, which left him with a corrupt VS, so he reinstalled his complete machine, and installed VS 2015 Update 1. The only add-on he installed is the SonarLint code analyzer, and he also has a constant CPU-usage of 30-40%.

[heejaechang]

@davidroth out of proc work is still going on so can't say what end form will look like. but plan is not bring all data up in memory so hopefully memory consumption is not like x3 (or number of processes) but like x1.5.

it is all about isolation vs data duplication. we want similar work to share data, but different work to have separate GC and CLR (so that we can recycle process without close and reopen VS ex, updating analyzers dll in use)

[heejaechang]

@davidroth yep, it could be OmniSharp for VS :)

[heejaechang]

@heejaechang hmmm, it is strange that VS is still using 30-40% CPU even after you turned off full solution analysis. all projects in solution is C# or does it have fixed solutions? also, when you get into high memory usage state, can you provide me a full heap dump so that I can see what's is using so much memory?

by the way, when you turned off full analysis for C# and VB, make sure close and rerun VS so that VS never does any work or cache anything related to full analysis.

[improwise]

I just can't believe how slow and sluggish Visual Studio 2015 is, it's beyond anything I've seen before. Just to try it out, we decided to install it on a Dell server with 128 GB of RAM, a quick SSD and a powerful Xeon CPU...and it is still slow and almost unusable sometimes!

As so many others have reported problems like these, both here and on other places on the net, I don't really see the need to provide any specific information as it seems we are just "one more the the same problems". It seems to work quite well with "code only" projects but as soon as you try to implement some kind of GUI, like WebForms, it's a real pain everyday to use these days.

Seriously Microsoft, what's going on here? I find myself more and more thinking about skipping .NET altogether and start looking for alternatives...

[heejaechang]

@improwise I am sorry to hear that. we first ask people to install our latest nightly (which has fixes for issues we know about) and turn off features we know expansive. if those don't make it better, only then we ask them to provide more information. since issues seem coming from something we don't know about yet.

...

about installing VS on powerful machine, unfortunately, all issues we are currently seeing seem coming from 32bit process limitation (especially memory space), and the limitation is same regardless how powerful the machine is or how much memory the machine has.

...

"as soon as you try to implement some kind of GUI, like WebForms, it's a real pain everyday to use these days."

hmmm.. these are new.. since those don't have anything special on how we process them compared to code only project.

by the way, are we talking about C# or VB? or some other languages?

[improwise]

@heejaechang

Thank you for responding. Problem is that, as mentioned by others above as well, we are already loosing a lot of time in our projects because of the shortcomings of VS2015 so we really don't have time to try out experimental versions of VS2015.

You are correct about the 32-bit limit of course. We just wanted to make sure it wasn't the normal laptops our developers use normally that were causing these problems and thus decided to try it out on a freshly installed powerful machine. But despite the difference in available performance, we didn't really notice any performance gains over our the powerful laptops our developers normally use.

Regarding GUI, the designer for webforms has always been on the slow side but in VS2015 this seem to have reached some kind of epic proportions. If you only have "code projects" like a class library project, they are usually much quicker (although many of the problems mentioned by others here affect us as well).

[heejaechang]

@improwise sure, we understand. but unfortunately, with big and complex software like VS, only way to make 100% sure we are addressing all issues are actually running fixes in a context where issues are actually reproing. otherwise, we might fix one specific problem, but not much overall on issues. that is why we are asking people to install and test them so that we can make sure next update fixes issues for customer who reported issues to us.

(we are trying to make testing nightly bit really simple and safe like installing/uninstalling a VS extension - vsix, it is still work in progress so there are some known issues, but we are in the work of ironing them out @jmarolf)
...

there are multiple aspects on sharing 1 VS 32bit process for all these complex works. one is memory but another is allocations. doing more works concurrently to boost performance (taking advantage of multiple cores) sometimes reduce overall performance due to sharing same GC. that is why. at certain threshold, we stop doing more work concurrently.

we are trying to overcome all these limitation by moving some parts of work out of proc. (but as usual, there will be con and pro such as using more overall system memory vs overall better perf or perf gets better as system gets powerful)

...

let me add web people for the issue you are having.

@barrytang Barry, @improwise looks like having issues with webform. is there any known perf issues you guys are addressing in update 3?

[improwise]

@heejaechang

To be honest, everyone I know of are having problems with VS2015 although to a different degree. It might be minor problems like having to reenter MSDN credentials every month to prevent the license from going stall, mysterious errors during build that go away if you rebuild a few times, or bigger problems causing major delays in development work lite performance problems, IDE crashing often etc.

Where can we get hold of somewhat stable but not yet released versions of Visual Studio 2015?

[heejaechang]

@jmarolf can you help @improwise to get nightly vsix?

...

by the way, this nightly will update Roslyn part of VS not whole VS. so updating vsix won't change C++ for example.

also, we do look every feedbacks reported to us. if you report issues through this,
https://msdn.microsoft.com/en-us/library/mt280277.aspx

we will have better information to diagnose the issue you are having.

[improwise]

Perhaps I should mention that even though VS2015 wasn't near to being a speed daemon or anything even on the powerful desktop (server) we tried on, we did notice that it was still not as slow as on the developers laptops. This of course isn't really a big surprise, as even though our developers use powerful laptops, they are still no where near the performance of a powerful desktop.

Edit:
That said, the laptops used by our developers are mostly brand new i7:s with fast SSD and at least 16 GB RAM so they should be more than capable of handling this...

[dolot3]

Today I started experiencing this memory leak issue - not sure if mine is the same as everyone else's. Mine started when I installed dojo.TypeScript.DefinitelyTyped so I could use dojo objects in TypeScript. After installing, I noticed that project compilation took several times longer than before. Memory usage goes up and down with each compile, but it never goes down as much as it goes up. Eventually I get the error 'Low Memory Detected' and have to restart VS2015. We have <10 projects in our solution - the largest one is an MVC app.

Hope that helps!

[jrood]

Same problem here. I had my machine completely re-imaged and did a fresh install of visual studio.

I've turned off 'Enable full solution analysis.' I've turned off animations. I've disabled 'track changes' for text editor. I've disabled source control. I'm not using codelense or resharper.

When I have it open, even if I never do any debugging and I'm only editing files, devenv.exe will start using more and more and more memory. I can watch it grow in task manager until it's up to like 2.2GB.

(edit) Uninstalling McAfee eliminated the problem.

[jmarolf]

@jrood Can you click on "Report a problem (Send a smaile)"

Select "Record your actions to reproduce the issue" and cc @heejaechang

[jrood]

@jmarolf When i click this button

nothing happens...there's no menu where I can click "Report a Problem..."

[jrood]

@jmarolf
however, you can see that, while I have no files open, and I'm not debugging, i'm still using 2gb ram

[jmarolf]

@jrood I don't doubt you, but I want to know _why_ :)

If you search for "report a problem" in quick launch (normally Ctr+Q) do you get this?

[jrood]

@jmarolf negative, I just get this

[jrood]

@jmarolf I was able to get to 'report a problem' through the menu. I'm currently waiting on 'Collecting information...'

[jmarolf]

@jrood So it was under "Help -> Send Feedback -> Report a Problem" but no where else? Sounds like a separate issue to look into on our end.

[jrood]

@jmarolf I actually just now briefly saw the menu pop up by the report a problem icon/button. (granted the last time I clicked it was probably 15 minutes ago)

[jrood]

@jmarolf ok i just submitted and did cc @heejaechang

[jmarolf]

@jrood THANKS!

[Pilchie]

@jrood - quick question for you. How big is the solution you opened? How many projects, and how many total C# or VB files?

[jrood]

@Pilchie the solution has 5 projects (2 apps and 3 class libraries). One app is an api with maybe 100 class files. The other is a web app with probably only 20 classes but plenty of html, cshtml, and js files. This might seem like a big solution to some...but I think it's important to recognize that this is pretty normal for any kind of enterprise application.

[Pilchie]

Thanks @jrood. Definitely a perfectly reasonable solution. I've been examining some cases with ~500 projects and 30,000 total files, which starts to introduce some other issues...

[AdamSpeight2008]

I've seen that error / warning when using the roslyn repo, and my machine has 40gigs of RAM, which it isn't fully using. It looks like it hits the wall at the 4 Gigabyte (or 32 bit limit).
Is this a process limit?

[improwise]

This is turning into a bad joke now, just restarted the computer, logged in, started VS2015, opened a solution with 3 small projects < 10 files each....and after 10 seconds I get a "Low memory detected" (more than half of physical RAM is still available).

(While at it, it would be nice if the Save/Save All functionality could be fixed as well, ie that it does what it should).

[markrendle]

Moving things like Code Analysis/Fixes, IntelliSense and so on into separate processes makes perfect sense. I was talking to one of the ReSharper/Rider engineers last week; they've refactored R# into a standalone service and consume it over a custom protocol from the IntelliJ-based (and thus JVM-based) Rider IDE, and it works so well they're looking at doing it for the VS plug-in too, and exploring whether the same principles could be applied in their other IDEs, like WebStorm.

It's already the standard way to create language-service plug-ins for other IDEs and editors, like VS Code, Atom, Sublime, etc: create the service in the language itself with a simple HTTP or process stdin/stdout protocol, then consume from Node.js or whatever. OmniSharp is an example, but it's also how Sublime runs TernJS, and so on.

Yes, there may be a slight memory overhead to running multiple processes, but it's a memory overhead that can be addressed with more RAM, or in the worst case by page files. Right now there's a 3GiB hard limit, and that doesn't cut it for an intelligent IDE in 2016.

(Oh, just for the record, here we're running the 64-bit versions of IntelliJ/WebStorm on VMware virtual desktops, and it's still dog-slow, so an x64 build of VS probably wouldn't solve these problems.)

[jrood]

I'm still having this problem in Update 3 RC

[heejaechang]

@jrood can you send us feedback as described above? looks like some issue with native side of allocations which we can't get through dump. we need virtual alloc information only exist in etl.

[jrood]

@heejaechang What do you mean? as described in which post above? When I did "report a problem" did that only send you a dump? How do I send you info from etl?

[heejaechang]

@jrood oh, sorry, yes, you reported it :) so many people on this thread. confused with other people. let me take a look and let you know.

[jrood]

@heejaechang ok cool

[heejaechang]

@jrood I am looking at your trace, description just says something is slow. can you be more specific? typing is slow? or building is slow? or typing while building is slow? are you saying machine is slow due to us using too much memory?

[jrood]

@heejaechang the issue is just that it's using over 2GB memory. I submitted it in the context of the conversation I was having with jmarolf above (5 days ago).

[heejaechang]

@jrood the feedback you gave me seems VS2015 Update 2 RTM. not update 3 RC. (14.0.25123.0)

unlike the dump sent by other one, you dump looks like inline with what we expect.

windbg shows
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 1441 8e4f1000 ( 2.224 GB) 55.59%
Image 9754 337ea000 ( 823.914 MB) 45.29% 20.12%
2356 32db2000 ( 813.695 MB) 44.73% 19.87%
Heap 263 8e3e000 ( 142.242 MB) 7.82% 3.47%
Stack 143 2660000 ( 38.375 MB) 2.11% 0.94%
Other 15 6a000 ( 424.000 kB) 0.02% 0.01%
TEB 46 58000 ( 352.000 kB) 0.02% 0.01%
PEB 1 3000 ( 12.000 kB) 0.00% 0.00%

2.2GB free memory, 800MB of images, 813MB of managed memory.

among 813 managed memory, 116MB is unreachable memory (garbage waiting for GC) so actual memory being used is about 700MB

among those we improved some of bit in update 3.

so, dump you sent seems not using more memory than we expects. (except those known issue in update 2 we fixed)

by the way, there is one reg key you might try to see whether memory consumption goes down with this tweak. (I dont actually know how your solution actually looks like, I see there are multiple projects, so some of this analysis is based on my assumption that your solution is a typical solution which has about 30 projects which having about 100 files)

in
HKCU\Software\Microsoft\VisualStudio\14.0\Roslyn\Internal\Performance\Cache
create DWORD key named "RecoverableTreeLengthThreshold" and put value "1"

we cache small files (actually parse trees) in memory to improve perf (so that we don't repeatedly re-parse small files) but if your solution has many small files, then we might cache too much. that regkey will let you not cache those all small files.

[jrood]

@heejaechang Thanks for the analysis! Yes I was still using update 2 when I submitted that. I just installed update 3 this morning.
What exactly does "free memory" mean? Does this really mean that no program is using it, or is this memory that Visual Studio has somehow claimed for itself, but it's not using?

[heejaechang]

@jrood here when we talk about memory, it always mean process memory not system memory. since VS is 32bit process which can only access 2GB to 4GB depends on your configuration (see this - http://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system). also since windows is modern OS which uses virtual memory, physical memory doesn't matter anyway. only memory limitation imposed by OS matter (for out of memory issue)

..

in the text above, free memory is free (not reserved process memory) for VS process.

I see this from your dump.
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 1441 8e4f1000 ( 2.224 GB) 55.59%
MEM_COMMIT 9836 64bbd000 ( 1.574 GB) 88.61% 39.35%
MEM_RESERVE 2742 cf42000 ( 207.258 MB) 11.39% 5.06%

basically, your VS process seems having 4GB address space. among those 1.5GB is committed and 207MB is reserved but not commited.

so, your process does use about 2GB. so you seeing 2GB seems inline with what the dump says. just about half of them is images (dll loaded to run VS. VS loads dll lazily, so the first time you uses a functionality in VS, dll that implements that functionality will be loaded into the process)

those images, we can't unload. more features you use, we will load more images to the process such as code analysis, code sense, designer, source control, emulator, azure, nfactory, performance tool, xamarin, apache cordova, unit tests and etc.

and surely all those features consume some of memory for themselves. and that seems about 700MB.

[jrood]

@heejaechang thanks so much for helping me understand this!
Under HKCU\Software\Microsoft\VisualStudio\14.0\ I don't have any folder called Roslyn. Should I?

[heejaechang]

yes, create the missing part.

[jrood]

@heejaechang thanks, I created it. How many small files is this caching feature intended to handle. Is it meant to handle up to 10,000 files?

[heejaechang]

@jrood not sure what you mean? are you trying to decide what to put inside of that DWORD? you should put 1.

[jrood]

@heejaechang yes I've already put a 1 in as the value. I'm trying to understand why this is not the default setting.

[jrood]

I uninstalled McAfee today, and my performance problems seem to have disappeared. I should have known.

[heejaechang]

@jrood good to hear that!. it is always hard to decide what should be default. our observation was for most of solutions, having some cache for small files to reduce re-parsing improved typing performance. and usually solution didn't have that much small files in the solution. that is why we choose the default we have now. but as we get more data and feedback, we sure will re-adjust the default.

[improwise]

@jrood Maybe I should install McAffe then to uninstall it :)

[rosdi]

My VS 2015 Enterprise will crash after a few hours of usage... I have to restart it every now and then. My solution isn't big, but I do work with javascript (specifically angular) a lot...

Could this be related?: http://briannoyesblog.azurewebsites.net/2016/05/25/visual-studio-2015-javascript-memory-leak/

I tried the solution suggested in the blog but does not seems to make a difference.

I will send a frown if it happens again.

[SamJongenelen]

I am not using AngularJS or any other web development package. I do use webservices (like WCF and other SOAP services), as well as various c# libraries

[rosdi]

Guys... after trying to reproduce this I can confirm it is Resharper's fault (for my case at least). I know @davidroth not using R# so my case is totally different than his... I will report mine to JetBrains instead.

For those using Resharper, try to suspend Resharper and WAIT 15 to 20 minutes (probably a GC thing)... the memory consumption should drop significantly (from 1.2Gb to only 650Mb in my case).

[chrislyse]

I thought maybe update 3 would help, but mine is now worse. My project used to run around 1.2GB of memory, then i ran one of the fixes found here and it was hovering around 800-900mb. Now after update 3 was installed it's at 1.5GB a few seconds after opening the project. I'm currently running a 30 day demo of Resharper, althought it was a bit laggy in the UI i did not see memeory change during the demo (i just started the demo a few days ago, after i started having all of the other memory issues). My I7, 32gb Ram laptop's fan runs like crazy after having my project open for a little while.

[heejaechang]

@chrislyse have you tried these? https://github.com/dotnet/roslyn/wiki/Performance-considerations-for-large-solutions

also, if you can send us frown, we can take a look to see what takes so much memory.

[Jgfrausing]

I am having the same problem. When debugging, the memory keeps increasing and after one hour VS hits 2.7 GB memory. Furthermore is it sometimes not possible to continue after a breakpoint. It keeps running, but just never gets any CPU time. The image is taken 10 minuttes after closing the solution and used memory is not dropping any lower.

[AdjutantML]

I would also like to confirm VS2015 (Update 2), major memory leak.
After only several hours of working with a +-100 source files project (refactoring and renaming), DevEnv is now sitting on 2.5GB.
I have been able to repeat this several times.

I have tried the suggestions @heejaechang posted above : https://github.com/dotnet/roslyn/wiki/Performance-considerations-for-large-solutions but they make no difference.

Dear VS team: Features are great, and well done for what you've improved.
However, at the cost of of stability and performance this is a major, major negative for VS and creates an very bad impression.
VS2012 used to start up my projects in less than a second.
VS2015 now takes up to 16 seconds. It is a disaster.

I strongly recommend going back to the basics. Allow us to turn off all the fancy stuff (_everything_) with the click of an option, to make performance and stability a top priority.

[davidroth]

@AdjutantML Memory usage has been improved in Update3. I'd recommend installing Update3 to verify if your issue remains.

[AdjutantML]

Thanks David - will do and report back asap later (Update3 is ~7.2GB :open_mouth:)

@chrislyse mentioned that Update3 did not help
Have you (or anyone else) confirmed as well?

[AdjutantML]

Update3 has not addressed the memory leak at all.
Merely 30 rename operations have pushed devenv.exe (from ~250MB) to over 1GB of RAM usage.

Update3 also introduced a random brand new bug, which specifically now makes renaming much more unpleasant : the keyboard cursor (caret) is randomly moved to another location in the active source file after the rename action.

New or changed features are not being sufficiently tested.
The scenarios above are easy to reproduce and basic functional testing would have flagged them.

Who wants a product that promotes features above stability?
We're moving back to 2013 Update 1. It works.

[davidroth]

@AdjutantML So you are saying 250 MB is your base value when opening your solution and you have 1 GB after some rename operations?
That doesn't mean that VS is leaking memory. When comparing memory usage make sure you press shift+alt+ctrl+F12 twice to force VS to do full GC.

Also keep in mind that temporary memory peaks when doing big source tree manipulations (refactoring) is a normal thing because your code has to be re-analyzed (requires new memory).
Memory should decrease as soon as a full garbage collection runs, which isn't deterministic.

Beside seeing 1 GB of memory, do you think VS is slow and unresponsive?

[AdamSpeight2008]

I've regularly have a perf hit when doing cmd line builds of Roslyn, do to it saturating of the all of the available CPU Threads (24 in my case). I think it could be reduced a little to leave a some threads availiable for the other applications. Maybe the cpu priority is too high?

[AdjutantML]

To be more exact:
devenv.exe uses 187MB after loading solution and waiting for it to stabilize (after 25 seconds).
Total project source files are only about 300.
Only 2 source files are loaded in the tab well.

The rename operations in question are also not that extensive - there may be a few dozen references to the member in question, but hardly more than several dozen.
The number of files affected are also not that many (in some cases it is even only a single instance in a single source file)

After 10 rename operations within the same active source file (not doing anything else), devenv.exe now consumes 366MB.
Waiting for 10 minutes without doing anything drops to 279MB.
After a single rename operation consumption immediately results in 303MB.
Another rename operation results in 311MB. (this was a case with only a single instance in a single source file).

Waiting another 5 minutes did not change consumption, still at 311MB.
Another rename operation increases usage to 337MB (again this member was used only once).
Pressed CTRL-ALT-SHIFT-F12 twice, hardly had any effect, changed to 330MB
Renamed another 3 times, memory up to 396MB
Pressed CTRL-ALT-SHIFT-F12 twice, hardly had any effect, changed to 385MB

The problem does not concern the logical operation of the tree size, otherwise a single operation would immediately consume a huge amount of RAM.
The problem is that VS is allocating RAM during the process, and is (most likely) keeping references to certain objects which are not being disposed - this is why consecutive operations keeping stacking memory usage. Agreed, the term 'memory leak' is a bit generic or broad in this case by I think you also understand what is implied.

Other versions did not have this problem, which clearly indicates that VS2015 is bugged.
I've just tested 2013 Update 5 and the initial memory required to perform the traversal is allocated, but thereafter no further memory is spent. Do you need more evidence?

Regarding performance:
The significant disappointment with performance does not stem from this particular problem but from a collection of other performance related problems. What annoys me most is an undertone of ignorance suggesting that VS performance actually is not slow at all, despite many user comments and complaints that it is slower than previous versions. In order to substantiate then, let me mention two sore points:

1. Unwanted and unused features (which cannot be easily disabled without hacking) cause VS load times to be much slower than previous versions. It is no exaggeration when I claim that VS2013 (without updates), on cold start, loads my example solution in several seconds, but a cold start load with VS2015 takes in the region of 20 seconds.
   Despite this I would like to praise VS2015 though for the caching improvements that have been made - these do noticeably speed up hot start scenarios.
2. The XAML designer has notorious performance problems, especially when switching between code behind and XAML - there are some bad design decisions here that made working with the XAML editor a inefficient painful experience.

The negative criticism above may appear distasteful but it feels necessary when issues are not acknowledged or given due consideration. I also have not retested the above performance comments with Update3.

[nicholashead]

@AdjutantML it's not really fair to compare VS2013 to VS2015 (especially Update 3), seeing as they are quite different feature-set wise. VS2015 is inherently doing more under the hood. Programs evolve and demand more resources as hardware becomes more powerful/performant. Update 3 definitely improved issues for me, but your mileage may vary obviously.

Do you have ANY third-party extensions/add-ons for VS2015 in use? I find that Resharper definitely causes performance issues with Visual Studio (2013 and 2015).

[heejaechang]

@AdjutantML Hi. we have 3 memory leak fixes waiting for next micro-update.

https://github.com/dotnet/roslyn/commit/53f1ae648dc5e71b4d4db681b85f9e599ad48bbb
https://github.com/dotnet/roslyn/commit/f965b894373e877badea39779e8b9b3068d347ae

both of them seem related to your scenario. I believe those micro-update will be released soon. if that still doesn't improve your scenario, can you provide us dump through "send a frown" menu?

[davidroth]

@heejaechang Nice to see further Perf improvements are in progress!
Memory usage has quite improved since Update 3, however, I am still seeing increased usage when doing branch switching (git). For example I can work many hours with stable me usage between 700-900MB but as soon as I switch between branches memory goes up and toggles between 1200-1500 Mb (and never gets back)

I believe this could be fixed with 53f1ae6?

[heejaechang]

@davidroth Hi David.

sound like this issue - https://github.com/dotnet/roslyn/issues/10358

no fix yet, but we are aware of the issue @Pilchie @jasonmalinowski

[AdjutantML]

Thanks @heejaechang, looking forward to it.

@nicholashead noted.
Also believe that the greater good should be served, if most users benefit and enjoy 2015 changes then I am an outlier, and let it be so.
No Resharper (have heard of Resharper related issues though) but do have Stylecop 4.7.50 installed. Plugins are exactly the same with VS2013 testing. Even if the plugins are related to triggering issues (specifically in VS2015), we have a clear cut case that can reproduce the problem without plugins and as heejaechang mentioned, this issue may be sorted already.

[davidroth]

@heejaechang thanks, yes #10358 looks exactly like the issue I described.
Sad that it is targeted for 2.0 though, which means we won't get a fix for vs2015?

[heejaechang]

@davidroth @jasonmalinowski is expert on project system. he is probably better person to answer that.

[jasonmalinowski]

@davidroth Can't say just because I literally haven't had the time to look at it. Let's discuss #10358 on that issue, rather than polluting this discussion further.

[DustinCampbell]

@Pilchie: could you track this?

[AdjutantML]

Good work guys, Update 14.0.25422.01 fixed the 'memory leak' (undisposed references).

On the topic of rename / refactor : Is it possible to persist the keyboard cursor position when starting a rename / refactor action?

This is what happens:

• The keyboard cursor is mostly (most often) already positioned at the precise offset where a change to a name must take place
• Refactor / rename (inline) is invoked
• VS automatically moves the mouse cursor to the end of the element
• The first keypress (left or right) moves the keyboard cursor to the very beginning or very end of the element
• The user must now move the cursor back to the position where the change was originally intended

When renaming by retyping the entire name (or typing a new name), it is possible to simply start typing (which is nice), but about 80% (or more) of the time I find that rename / refactor operations consist of only a few letters.

Is there a way to restore or enable such functionality (persist the cursor location - i.e. do not move the cursor to beginning or end of element)?

[DickvdBrink]

@AdjutantML, you don't need to invoke the refactor rename first. You can just do some changes and press ctrl+. and it will asks you to rename it. That is your usecase if I'm understanding it correctly.
But maybe you should make a new issue for this because this thread is more about memory leaks than rename/refactor ;)

[AdjutantML]

@DickvdBrink, that is perfect!
Thanks for the the info.

[Pilchie]

At this point, I think the issues that triggered this thread seem to be mostly addressed, or already tracked in other issues. I'm going to close this issue, but please continue to file new issues for specific problems that you're seeing - improving performance and memory issues is one of our top focuses for 2.0/VS "15".

[msedi]

I have installed VS2015 14.0.25425.01 Updated 3 but still having problems with memory. When I start VS at the evening with full available memory and leave VS open during the night, come back in the morning and there is almost no memory left (2GB of 32GB). If I look in the process explorer I can see not application that keeps the memory, also Resharper is turned off.

[AdamSpeight2008]

@msedi Would you mind expanding on "left open".

• Is this just the initial screen, no solution / code open.
• Is there a projects loaded?
  etc

[Pilchie]

@msedi Can we please move this to a new issue. You appear to be talking about something other than the actual VM used by the devenv.exe process, which is limited to 4GB being a 32-bit process.

[msedi]

@Pilchie: You may be right and I'm not quite sure who is using the memory. It seems that VS isn't using the memory, also when using the ProcessExplorer there is nothing that tells me who is using the memory. Where VS is still used as a 32bit-Process I'm aware that the process "devenv" is obviously not using it. Of course I can open up another issue, but I thought it fits here. BTW: The 32GB was related to the memory in my computer and someone is eating the memory, but I cannot find out who ;-)

[msedi]

@AdamSpeight2008: Sorry for being to vague. VS is left open with all projects loaded. In other words, I work with VS, compile things, leave the solution open, and when I stop working and go home, I leave VS in it's current state - simply don't touching anything anymore.

[jmarolf]

@msedi If you launch Task Manager (Ctrl + Shift + Esc) and sort by memory usage what do you see?

Also, what OS are you using?

[msedi]

@jmarolf I have installed Windows 7/x64. Attached are two screenshots of my running processes

[jmarolf]

@msedi

When I start VS at the evening with full available memory and leave VS open during the night, come back in the morning and there is almost no memory left (2GB of 32GB).

This does not appear to be happening in your screen shots. Please file a new bug if you find out that devenv.exe is taking up all of your system memory.

[timeichfeld-msa]

Just an observation: Why is this issue closed? I am seeing this issue on Build:
-=-=-=-
Microsoft Visual Studio Community 2015
Version 14.0.24720.00 Update 1
Microsoft .NET Framework
Version 4.7.02556

Installed Version: Community

Visual Basic 2015 00322-20000-00000-AA351
Microsoft Visual Basic 2015

Visual C# 2015 00322-20000-00000-AA351
Microsoft Visual C# 2015

Visual C++ 2015 00322-20000-00000-AA351
Microsoft Visual C++ 2015

Visual F# 2015 00322-20000-00000-AA351
Microsoft Visual F# 2015

Application Insights Tools for Visual Studio Package 1.0
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2015.1 (Beta8) 14.1.11106.0
ASP.NET and Web Tools 2015.1 (Beta8)

ASP.NET Web Frameworks and Tools 2012.2 4.1.41102.0
For additional information, visit http://go.microsoft.com/fwlink/?LinkID=309563

ASP.NET Web Frameworks and Tools 2013 5.2.30624.0
For additional information, visit http://www.asp.net/

AWS Toolkit for Visual Studio 2015 1.10.0.6
AWS Toolkit for Visual Studio 2015.
Copyright 2011-2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.

This software includes third party software subject to the following copyrights:

• Logging from log4net, Apache License
  [http://logging.apache.org/log4net/license.html]
• Putty for PPK to PEM conversion, MIT license
  [http://www.chiark.greenend.org.uk/~sgtatham/putty/licence.html]
• NGit for AWS Elastic Beanstalk incremental push
  [https://github.com/mono/ngit/blob/master/NGit.license.txt]
• NSch dependency for NGit
  [https://github.com/mono/ngit/blob/master/NSch.license.txt]
• Sharpen dependency for NGit
  [https://github.com/mono/ngit/blob/master/Sharpen/AssemblyInfo.cs]
• ICSharpCode.SharpZipLib dependency for NGit
  [http://www.icsharpcode.net/opensource/sharpziplib/]
• Mono.Posix.dll and Mono.Security.dll dependencies for NGit
  [http://mono-project.com/FAQ:_Licensing#Licensing]
• MPFProj for Visual Studio Project Framework
  [http://mpfproj10.codeplex.com/license]
• JSON Checker for JSON validation
  [http://www.raboof.com/projects/jsonchecker/]

Common Azure Tools 1.5
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

CreateLayoutWizard 1.0
Create layout wizard.

Devart Code Compare 4.1.78
Devart Code Compare
Copyright (c) 2012-2015 Devart. All rights reserved.
http://www.devart.com/codecompare/

DevExpress.DeploymentTool 1.0
A useful tool for deploying DevExpress assemblies.

Entity Framework Power Tools 1.0
Adds useful design-time DbContext features to the Visual Studio Solution Explorer context menu.

When right-clicking on a file containing a derived DbContext class, the following context menu functions are supported:

1) View Entity Data Model - Displays the underlying Code First model in the Entity Framework designer.
2) View Entity Data Model XML - Displays the EDMX XML representing the underlying Code First model.
3) Generate Views - Generates pre-compiled views used by the EF runtime to improve start-up performance. Adds the generated views file to the containing project.

GitHub.VisualStudio 2.3.6.391
A Visual Studio Extension that brings the GitHub Flow into Visual Studio.

JetBrains ReSharper Ultimate 2016.3 Build 107.0.20161214.141528
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2018 JetBrains, Inc.

Microsoft Azure Mobile Services Tools 1.4
Microsoft Azure Mobile Services Tools

NuGet Package Manager 3.3.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

PreEmptive Analytics Visualizer 1.2
Microsoft Visual Studio extension to visualize aggregated summaries from the PreEmptive Analytics product.

SQL Server Data Tools 14.0.50616.0
Microsoft SQL Server Data Tools

XtraReports package 1.0
XtraReports package

-=-=-
When VS gets over 1.0 GB of memory usage, performance lags considerably, to the point where it is unusable. My fix is to restart Visual Studio... but doing this every couple hours is not productive. Thoughts?

Should I open a new issue?

[nicholashead]

@timeichfeld-msa yes, but I would also suggest maybe you give the newest VS a try?

[timeichfeld-msa]

Understood, I will try that. Thanks!

[heejaechang]

@timeichfeld-msa when this happen again, can you create a full dump and provide the dump to us? that will help us to figure out what is consuming so much memory.