Open jkoritzinsky opened 6 months ago
Tagging subscribers to this area: @dotnet/interop-contrib See info in area-owners.md if you want to be subscribed.
Author: | jkoritzinsky |
---|---|
Assignees: | - |
Labels: | `area-System.Runtime.InteropServices`, `source-generator` |
Milestone: | - |
Love it! For context, here's my IndentedTextWriter
, if you want to reuse or adapt this for the interop generators. It also has a couple of interpolated string handlers included (I'd imagine you already have polyfills for the necessary types, but if not you can either just link them from corelib or perhaps use PolySharp) 🙂
FWIW, the regex generator has been using the built-in IndentedTextWriter and it's worked fine. https://github.com/dotnet/runtime/blob/0fae364617f03d1003af0f0b49e57876e51875d4/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs#L106
In case if anyone is unaware, there is also an indented string builder proposed at roslyn side: https://github.com/dotnet/roslyn/issues/71162
Since the start of the interop source generators, we've always decided to use Roslyn
SyntaxNode
s as both our source-of-truth as well as our go-to emit strategy. This choice has provided us a number of benefits:However, it has also lead to a number of problems:
NormalizeWhitespace
(what we use to handle adding whitespace) is extremely slow.SyntaxNode
s in the sourceSyntaxTree
s due to how we structure some of our internal data types.SyntaxNode
tostring
for Roslyn to parse anyway.Additionally, the Roslyn team recommends using a
string
-based approach.Finally, @Sergio0694 updated ComputeSharp to use an "indented text writer" approach and saw a ~460x performance improvement in CPU time and a ~36x Memory footprint improvement. Even if we only get a fraction of that improvement due to our desire to have an extensibility model, doing the work to rewrite the APIs seems worthwhile.
Additionally, with that amount of improvement, we may also see build-time improvements for assemblies with lots of
LibraryImport
s, such as CoreLib.