Perf improvement opportunities

[AArnott]

As a continuation of ongoing perf work, this issue tracks perf improvement opportunities.

• Calling PEReaderExtensions.GetMetadataReader is apparently quite slow because of some in-memory buffer copies. We can pool and recycle the result of this call.
• TryGetEnumName exhaustively searches all enum values in the metadata on every call. On subsequent generations, we should be able to reuse the result of this search rather than repeating it.
• GetMethodsByName spends a lot of time concatenating strings and in 3 dictionary lookups per namespace in the search. We may be able to consolidate this to just 1 dictionary lookup with no string concatenation.
• TryGenerateConstant spends a lot of time in direct dictionary lookups (one lookup per namespace searched). We might be able to get this down to just one lookup.
• TryGenerateType spends a lot of time in direct dictionary lookups (one lookup per namespace searched). We might be able to get this down to just one lookup.
• SyntaxNode.GetText, which renders the syntax tree to a SourceText, takes a significant amount of time (as of course does the production of the syntax tree. If we could cache this and safely determine when we can reuse it, that would be supreme.

Some of these items come from this table.
See also #244 for prior work in this area.

[AraHaan]

The generator already uses the IncrementalGenerators feature right?

If not, that might also increase performance significantly as well.

[AArnott]

No it doesn't, @AraHaan. That is something we may be able to capitalize on in the future. In fact #355 was an attempt to do that. It's hard to know when we can really reuse generation because so many little changes in the user's project that might seem unrelated to the generated code can actually impact it.

[AraHaan]

True, that is why you have to carefully design it to where it is smart as to when it should kick in, and when it should not.

As for that, perhaps someone from the Roslyn team could help with the migration to that as well.

Alternatively it could be made to kick in only when it sees that the additional file that the generator uses has been edited since the last time it ran.

[AArnott]

it could be made to kick in only when it sees that the additional file that the generator uses has been edited since the last time it ran.

That isn't the only input file. Adding or removing a partial modifier to a user type for example could change how we generated code in CsWin32. In other words, a change to any source file in the compilation could have an impact. Adding/removing references also can have an impact. Changing the C# langversion has an impact. Very few things can change that we know will not have an impact.

That said, if we did an impact assessment as the first step in generation, that may be less expensive than the generation itself and if so, since most changes the user may introduce won't end up impacting generation, it will net a perf win for the user.

[ghord]

Due to serious perf impact of having cswin32 in a project, I always refactor it to separate PInvoke dll with public: true. Doing this improves visual studio experience very noticeably, as adding cswin32 to a project with even single winapi method degrades VisualStudio experience.

Could you consider NativeMethods.json switch that determines when codegen runs? For example, I would love the setting to only rerun code generation when NativeMethods.txt/json/project references change. I'm pretty sure I've never used cswin32 where it matters what types have partial modifier. I think that removing dependency on the user typing c# code would improve the situation tremendously.

[jevansaks]

There's now a CsWin32RunAsBuildTask mode which stops CsWin32 from running as a source generator. If you are sensitive to performance, I'd recommend switching to that mode. It will also give you better .NET AOT support as it's compatible with the LibraryImport and GeneratedComInterface source generation.