Source Generators on save

[YegorStepanov]

Is it possible to run source generators on save only, not real-time?

The IDE experience degrades a lot with the frequent use of source generators

[sharwell]

The IDE experience degrades a lot with the frequent use of source generators

We get this feedback often, but our observation over time is this is not true for cases where the source generator was optimally written using Roslyn's new APIs. The request to only run the source generator on save thus eventually reduces to a request to require users to opt-in to a work around for an inefficiently written source generator. It would be better to fix the source generator itself, thus not requiring a new user option and not having the performance problem.

If you can provide more information about the goals of the source generator and the reason why you believe it is causing performance problems, we will likely be able to provide tips for correcting it.

[YegorStepanov]

I don't write them, I just use them.

The request to only run the source generator on save thus eventually reduces to a request to require users to opt-in to a work around for an inefficiently written source generator.

• Not everyone has the time to write a Roslyn-correct super-efficient generator.
• I'm not sure that the users want to think about caching, fast exits.
• It will reduce the cost of writing it if you can do it in an easier way. So more users will write it.
• Some generators can be very heavy.
• The experience almost will be the same.
• I don't know any generator that should work on every symbol.

The [LoggerMessage] is added in .NET 6. Does its generator run on every symbol? Even when I write "Hello world" program?
Is the cost constant?
If [LoggerMessage] generator needs 1000 CPU cycles for a small program using the attribute, would that also require 1000 cycles for a huge codebase?

[sharwell]

Logger message generator should only run if you change the signature of a logger method. It shouldn't run if you are just calling the logger method. We spent a good bit of time optimizing this one, and I haven't seen it show up as the cause of performance problems. We would certainly work to optimize it if we saw it showing up in performance traces.

[YegorStepanov]

Oh, .NET previews suffered from SG v1.

Since you had many reasons for adding the checkbox but decided not to, I'll close the question and wait for the libraries to be updated to SG v2.

We get this feedback often

Did not find any discussion about it.

[sharwell]

and wait for the libraries to be updated to SG v2.

This work should already be complete for source generators that ship in the SDK. If there are others that are still causing problems, please feel free to point them out to us so we can work with those authors to update them.

[YegorStepanov]

Thanks for the concern.

I use them in a home project:

WindowsCommunityToolkit: they've already moved to V2 but haven't updated the library yet.
StrongInject: want to add it but worried about IDE performance.

[xoofx]

I quite concur with the ask here. The default should have been to run a source generator only on save, not on every single key strokes. Even when using incremental source generator, it doesn't help when you see your generator running just because you changed a whitespace in a comment on the file and you are not done with your changes.

I don't know what is the real use case for realtime changes on every single key stroke, but I can't think of any for all the use cases I have been using it so far.

[mnmr]

If your generator is properly incremental then no one should have a performance hit. Your converters and metadata should only regenerate when necessary already.

It is not necessary for them to be regenerated every time the source changes. That is, in fact, completely unnecessary, and therefore constitutes a performance hit I'd rather be without.

Note: this is better than "compile on save" as it will not be a burden for users who save a lot (like myself). Because you are incremental, you won't have to pointlessly regenerate when nothing of interest is changing.

My main interest is in an OnBuild option, which is not coupled to the save frequency. That said, if you can do an incremental generator that only does work when there are changes, the same system could be used in a save-triggered environment, so I don't really see your argument as being very strong here.

[CyrusNajmabadi]

It is not necessary for them to be regenerated every time the source changes.

That's how an incremental generator already works. It only regenerates if something of relevance has changed and can this affect the final generated source.

[mnmr]

It is not necessary for them to be regenerated every time the source changes.

That's how an incremental generator already works. It only regenerates if something of relevance has changed and can this affect the final generated source.

I'll just assume that I am really bad at communicating, because as I see it that is absolutely not how it works.

Perhaps it'll help to list the two scenarios as I understand them:

Incremental generators:

1. Gets triggered on source changes
2. The generator has code to quickly exit if the modified symbol wasn't relevant
3. The generator has additional code to bypass source generation, or only do some of its work, deferring other parts for later
4. Eventually the later part gets to run to emit the final code
   => Impact on IDE: Some on every keystroke, some more when a relevant symbol is modified, some more when final code is emitted

Generate on build:

1. Scan symbol set in current compilation for relevant symbols
2. Emit code for those symbols
   => Impact on IDE: Only when building

These two scenarios are not the same. The first introduces a bunch of complexity into the generator, which for a lot of cases simply isn't needed. And it's not like source generators are non-complex to begin with, given that you have to learn both how they work and how to work with the Roslyn symbols.

[CyrusNajmabadi]

Gets triggered on source changes

That's not really what happens. Roslyn is a 'pull' architecture. Features (of which there are literally hundreds, as well as whatever comes through from extensions) work on their own cadence and ask for semantic information. To get that accurate semantic information (which our apis have always provided), and which features (internal and external) ask for, that requires generation of SG content.

However, incremental sgs can be smart. By seeing that the changes from the prior computation to this computation would not change results, they can avoid any generation actually happening.

[CyrusNajmabadi]

Only when building

This is not a concept. There is no 'build' that pushes things along. E.g. we don't push parsing and semantics along with external events like building. We don't push them along with typing either. Instead, as mentioned above, it's all "pulling" and features (like analysis) request what they want. This is an extensible ecosystem as well (like SGs are) so analyzers do things like ask for correct information so that can give correct diagnostics.

[xoofx]

I have proposed an extension of this issue at #64173