This repository has been archived by the owner on Dec 18, 2017. It is now read-only.
[Performance] DTH should defer compilation for project load scenarios #883
Comments
Notes from our combined sessionBreak resolution into stages DTH changes light
heavy
caching
advanced
timing?
|
davidfowl
added a commit
that referenced
this issue
Nov 22, 2014
- Break processing into 2 stages. - Project information and dependency resolution - Compilation - Added caching to the dependency resolution and added a project.json cached dependency. - Modified ProjectExportProviderHelper to be public and to only allow filtering the exports via a predicate. - Removed ANIs from source completely (this will make an appearance in a later change) - Always compile when GetDiagnostics or GetCompiledAssembly is called - This should also greatly reduce the amount of memory consumed by default. The trade off is that we need to compile on demand when the runtime requests but that seems to be very fast once roslyn is warm. #883 #889
davidfowl
added a commit
that referenced
this issue
Nov 23, 2014
- Break processing into 2 stages. - Project information and dependency resolution - Compilation - Added caching to the dependency resolution and added a project.json cached dependency. - Modified ProjectExportProviderHelper to be public and to only allow filtering the exports via a predicate. - Removed ANIs from source completely (this will make an appearance in a later change) - Always compile when GetDiagnostics or GetCompiledAssembly is called - This should also greatly reduce the amount of memory consumed by default. The trade off is that we need to compile on demand when the runtime requests but that seems to be very fast once roslyn is warm. #883 #889
|
Though this is fixed in general, there is one more issue. For a non-compatible framework, (Web project has aspnetcore50 whereas .csproj is only targeting net45) and if the user added the dependency to a common section, DTH should return the reference as unresolved for non-compatible framework, however right now it's returning the wrapped project.json for non-compatible framework and returning the backing .cspoj for compatible framework. The above needs to be fixed, hence opening the issue again. |
|
oops, wrong issue, will add the info to the right one... |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This was discussed internally. The DTH process (klr.exe) takes a lot of system resources when running while we open the project in Visual Studio and this is the major component of performance delays we see with opening projects.
The thinking was to do enough processing initially to give the list of source files and references to VS (for intellisense) and compile at a later stage when needed.
The text was updated successfully, but these errors were encountered: