I’m considering creating a package with Roslyn analyzers/generators to reduce regular code bloat candidates, like, component caching came to my mind first.
I’m worried about the performance of source generators for larger projects though, as generators run on each source code change, as I understand.
Roslyn recognizes this problem and added an interface for incremental source generators: roslyn/docs/features/incremental-generators.md at main · dotnet/roslyn · GitHub.
Those can filter the compilation for source they are interested in beforehand, and only run if that source actually changes, as I understand.
Unfortunately, that interface added in the release of Microsoft.CodeAnalysis 4.0.1, and Unity only works with generators using Microsoft.CodeAnalysis 3.8.0 (Unity - Manual: Roslyn analyzers and source generators).
I do not know the implications, but is there a plan for an upgrade to support newer releases of this package?
Sorry, I’ve interacted with Roslyn analyzers just a bit a few years ago when I tried using StyleCop in a medium-ish sized project, so I might be completely missing the point here.
Have you tried using Rider? From what I see, the component caching does get picked up by its analyzer automatically and I’ve never had issues with Rider missing something I was aware of.
Hi, analyzers are working and performing just fine for me. Also the whole Roslyn code analysis package behavior does not differ between IDEs because, as the name implies, the IDE is just reporting what the Roslyn compiler is reporting and generating for it. Just JetBrains ReSharper and Rider diagnostics differ because they are not based on Roslyn but do their own analysis disregarding the actual compilation. I’m currently using and loving Visual Studio + ReSharper, which is probably the slowest combination in the mix, but I’m fine with the performance. The API allows you to plug into different steps in the compilation (which is partly also execute while live-editing) to reuse information that is available at the current stage. While solution-wide analysis is slow, it is hardly ever needed anyway.
Source generators are different though, although they smartly use the same API, data, assembly reference type and interface, because the automated source generation is based on analyzing the existing code first anyway. Source generators scrap and regenerate in-memory C# (or other) files on every code-editing keystroke, based on all source files that are part of the compilation. While you can do amazing stuff with them for reducing code bloat, redundant coding and relying on slow methods like reflection, they have been reported a lot to not perform great on larger codebases, i.e. slowing down the IDE, which does not come as a surprise. In version 3.8.0 they have been anyway in their baby-steps, while code analysis diagnostics and code fix providers have been around much longer.
So a newer API was released, actually this or last year I think, that allows you to keep and reuse generated source as long as there are no code changes that do not concern a generator, which is incremental source generators, but those are documented, and I can confirm, to not work in Unity. Now I do not know what Unity would have to update to make them available, but I feel like there is quite some redundancy when working in Unity, and especially considering the importance of performance in games, I feel like incremental source generators would be of big value.
I will anyway go ahead and write some regular source generators and see how they perform, but I fear that they might not be well usable in actual regular-scale projects.
@michi_b I’m actually in a similar situation. Have you maybe tried to go on with incremental generators?
I don’t know about Incremental Source Generators, but you can limit the “scope” of your Unity analyzer / generator, by putting the code in a own folder with a assembly definition and then move the generator plugin inside this folder.
The generator should only be used by code inside the assembly definition. (I did not try this with generators yet, but according to the documentation this should work the same way as it does with the analyzers)
Not sure if this is a good solution for you, but you could try it, if you don’t mind splitting your code into assembly definitions.
I would also really like to see an update to the 4.0.x version of CodeAnalysis. The normal source generators are cool, but incremental generators are the only workable solution once the generated code reaches a certain size.