What makes a source generator incremental, and how do you keep a generator from slowing down the IDE?

How I would answer this in an interview

An incremental source generator is one whose work is expressed as a pipeline of cached steps, so that when a developer types, Roslyn re-runs only the steps whose inputs changed — and skips the rest by comparing step outputs for equality. The IDE runs generators continuously (on almost every keystroke), so a non-incremental or poorly designed generator directly slows down IntelliSense, typing and builds. The key techniques are: fast syntactic filtering (ideally ForAttributeWithMetadataName), value-equatable models, avoiding the whole Compilation in the pipeline, and testing incrementality.

1. How incrementality works

SyntaxProvider (attributed classes)  ──Select──>  TypeModel (record of strings)  ──>  RegisterSourceOutput
          ↑ re-runs only for changed files        ↑ cached if equal to last run         ↑ skipped if model unchanged

• Each node in the pipeline caches its outputs from the previous run.
• When input changes (a file edit), Roslyn recomputes affected items, then compares new outputs with cached ones using Equals (or a custom comparer).
• If outputs are equal, downstream steps don't run — including source generation and the expensive recompilation that follows when generated text changes.

2. What makes a generator incremental (in practice)

1. Implement IIncrementalGenerator (not the old ISourceGenerator, which runs everything every time).

2. Filter early and cheaply:

context.SyntaxProvider.ForAttributeWithMetadataName(
    "MyLib.GenerateMapperAttribute",
    predicate: static (node, _) => node is ClassDeclarationSyntax,     // syntax-only, very fast
    transform: static (ctx, ct) => BuildModel(ctx, ct));

ForAttributeWithMetadataName uses the compiler's attribute index and is dramatically faster than CreateSyntaxProvider scanning all nodes with semantic checks. Keep predicate purely syntactic; do semantic work in transform only for candidates.

3. Produce value-equatable models:

internal sealed record MapperModel(string Namespace, string Name, EquatableArray<PropertyModel> Properties);
internal sealed record PropertyModel(string Name, string Type);

• Records give value equality, but ImmutableArray<T>/List<T> compare by reference — wrap collections in an EquatableArray<T> struct implementing sequence equality.
• Never put ISymbol, SyntaxNode, SemanticModel, Location or Compilation into models: they're different objects every run (so equality always fails), and they keep entire compilations alive in memory.
• If you need locations for diagnostics, store a lightweight equatable location (file path + text span).

4. Avoid CompilationProvider in the main path: Combine(context.CompilationProvider) changes on every edit, invalidating everything downstream. Extract only what you need (e.g. a single type's presence) via Select with a value result, so caching still works.

5. Split work by item: process per type/file with IncrementalValuesProvider, not one big Collect() of everything (a single change would regenerate all output). Use Collect() only when you truly need an aggregate (e.g. a registry file), and keep the collected model small and equatable.

6. Keep RegisterSourceOutput cheap and deterministic: string building only; same input → same output text.

7. Respect cancellation: check CancellationToken in transforms; the IDE cancels runs frequently.

3. Keeping the IDE fast

• Use RegisterImplementationSourceOutput for code that doesn't affect IDE semantics (e.g. method bodies that don't change the public shape), so the IDE can skip it during design-time builds.
• Avoid heavy dependencies and reflection inside the generator.
• Don't read files from disk directly; use AdditionalTextsProvider (cached and tracked).
• Generate less code: share helpers via a runtime library or post-initialisation output instead of repeating them per type.
• Measure: the IDE's "generator performance" diagnostics, dotnet build -bl with /p:ReportAnalyzer=true showing generator time, and Roslyn's ETW/EventSource events.

4. Testing incrementality

var driver = CSharpGeneratorDriver.Create([new MapperGenerator().AsSourceGenerator()],
    driverOptions: new GeneratorDriverOptions(IncrementalGeneratorOutputKind.None, trackIncrementalGeneratorSteps: true));
driver = driver.RunGenerators(compilation);
var edited = compilation.AddSyntaxTrees(CSharpSyntaxTree.ParseText("class Unrelated { }"));
driver = driver.RunGenerators(edited);

var result = driver.GetRunResult().Results[0];
Assert.All(result.TrackedSteps["BuildModel"].SelectMany(s => s.Outputs),
    o => Assert.True(o.Reason is IncrementalStepRunReason.Cached or IncrementalStepRunReason.Unchanged));

Name steps with .WithTrackingName("BuildModel") so tests can inspect them.

5. A production example

After adding an in-house mapping generator, developers on a 300-project solution complained that typing lagged and Visual Studio's CPU spiked. The generator used CreateSyntaxProvider with semantic checks on every class, combined with CompilationProvider, and stored INamedTypeSymbol in its model. We rewrote it to use ForAttributeWithMetadataName, value-equatable models and per-type outputs, and added incrementality tests. Generator time per keystroke dropped from hundreds of milliseconds to near zero and the lag disappeared.