This repository has been archived by the owner on Dec 18, 2017. It is now read-only.
OOM when using MVC solution in VS #2681
Comments
davidfowl
added a commit
that referenced
this issue
Sep 19, 2015
davidfowl
added a commit
that referenced
this issue
Sep 20, 2015
- Create one every time. The memory is all working memory and doesn't need to be held onto. #2681
|
@rynowak let me know if you see the problem still. The changes drop the memory that is being held onto. There's another issue to just reduce allocations in general which will be submitted later. |
|
This is still happening. There's too much stuff rooted - I get into this state working with either MVC solution for about an hour.
Dump is available on corpnet. |
davidfowl
added a commit
that referenced
this issue
Sep 25, 2015
- There were some general regressions from beta7 to beta8 wrt performance of DTH and compilation. This fix intends to rectify those and also improve some on some of the older logic (<= beta7) - Don't create the build time load context until required. For it's not needed unless a compile module is being loaded or a custom compiler is being loaded. - The LibraryExporter no longer holds onto the build load context - Fixed a disposal caching bug - Nuke IProjectGraphProvider because it provided no real value - Made ProjectExportContext which acts as a disposable cache entry for the build time load context. - Added friendly name to LoadContext for easy debugging - Removed background compilation from DTH as it was harmful for large solutions. Things are only compiled on demand now. - ProjectAssemblyLoader will only take the subset of project that it needs #2681
|
@rynowak if you see more issues, please reopen again 😄 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Seems we're holding onto a bunch more library descriptions. This can easily be fixed by caching more strings, versions, package ids, paths.
The text was updated successfully, but these errors were encountered: