Roslyn workspace should share SyntaxTrees across project targets when possible.
See original GitHub issueFrom talking with @jasonmalinowski we believe there would be a large memory savings here for solutions with projects that multi-target (e.g. netstandard2.0, netcoreapp3.1, etc.). The cases that should be very safe to share are ones where the tree does not contain pp-directives, and where the lang-version for different targets are the same.
The reason for this is that pp-directives can parse differently depending on what PP directives are defined. And lang-version can affect how certain constructs are parsed (like records), as well as affect what errors are reported (like if certain constructs are or aren’t supported).
- It would be valuable for us to collect some telemetry to see what percentage of projects that are using multi-targetting end up using the same lang-versions. On top of that, it would be good to keep track of what percentage of their files do/do-not use pp-directives.
- we currently do keep track of stuff like pp-directives for fast-switching of debug/release. However, that tracking could be finer-grained. I believe we check if there are any directives, where we really only care about
#if
directives. e.g.#region
and#nullable
shouldn’t change things here. - Roslyn would be a great test bed for this as we have many targets, and tons of files. We could get a huge win here, that would translate out to projects similar to ours.
- We may want to drive compiler APIs to assist us here. For example, it would be great if we could cheaply just ask if a file contains pp-directives. This could be a weak heuristic (potentially even at the source-text level). For example, just asking if any line starts with
spaces-#-if
. Or just allowing this to be determined from a green tree, etc.
Issue Analytics
- State:
- Created 10 months ago
- Reactions:3
- Comments:16 (16 by maintainers)
Top Results From Across the Web
getting Project instances in a .NET core workspace · Issue ...
I've been looking at removing the MyGet dependency from the Noda Time build - I'd hoped that now that Roslyn 2.3 is out,...
Read more >Unable to GetDocument using SyntaxTree
Looking at the samples coming with Roslyn I found that I need SymbolFinder.FindReferencesAsync(theType, solution) . I created File->NewProject ...
Read more >Introduction to Roslyn and its use in program development
Roslyn is a platform which provides the developer with powerful tools to parse and analyze code. It's not enough just to have these...
Read more >Work with the .NET Compiler Platform SDK workspace model
This overview provides an understanding of the type you use to query and manipulate the workspace and projects for your code.
Read more >Page 6 - Shotgun Debugging
A workspace that allows one to add solution and project files manually. One should note that the API for adding and removing solution...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Done with https://github.com/dotnet/roslyn/pull/66003.
@jaredpar We could totally aggregate that data and send it up if you wanted the telemetry, so that’d be another good argument for it.
@CyrusNajmabadi For our syntax tree indicies, I know you made changes so they could be reused across debug/release switches – do we also try to share them across multiple targets? Or do we hash the parse options into that?