This article is more than 1 year old

Faster than reflection: Microsoft previews Source Generators for C#

.NET is getting faster but will not be as efficient as C++ or Go. Reason? Legacy code

Microsoft is previewing a new C# compiler feature called a Source Generator that it said will automatically spit out new source code and compile it when you build a project.

The feature is in the latest .NET 5.0 preview, where .NET 5.0 is the forthcoming release that is intended to unify the Windows-only .NET Framework and the cross-platform .NET Core. Another way of looking at it is that it extends .NET Core to be useable as a replacement for .NET Framework.

The announcement by program manager Phillip Carter describes the new feature succinctly. "A Source Generator is a piece of code that runs during compilation and can inspect your program to produce additional files that are compiled together with the rest of your code."

The question is: why?

Source Generator adds generated code as part of the compilation process

Source Generator adds generated code as part of the compilation process

According to Carter, the main immediate value is as an alternative to a feature of .NET called runtime reflection, by which .NET code can analyse assemblies (units of compiled code) at runtime to discover the types and objects, read properties and invoke methods. "For example, ASP.NET Core uses reflection when your web service first runs to discover constructs you’ve defined so that it can 'wire up' things like controllers and razor pages," said Carter.

Reflection takes time, and the Source Generator could potentially perform these tasks during compilation, improving performance. Many commonly used libraries, including the .NET parsers for Json and for regular expressions also make heavy use of reflection. Reducing the use of reflection would enable better optimisation for AOT (ahead-of-time) compilation, Carter said.

Are Source Generators similar to macros, which also generate code before compilation. "The key difference is that Source Generators don’t allow you to rewrite user code," Carter added, answering this and other key questions.

There are some snags, with the biggest being that this is currently a C#-only feature. It is unlikely ever to come to Visual Basic, since Microsoft has said that "we do not plan to evolve Visual Basic as a language."

It may or may not come to F#, depending on feedback. This means that library and framework developers who wish to support VB or F# will need either to do so without Source Generators, or code stuff twice with reflection as a fallback.

Adding to the confusion, Carter said that Source Generators are "not technically a C# language feature," though they are being introduced (all going well) for C# 9.0.

If you want to dig into the possibilities offered by Source Generator, a good place to start is the Source Generator Cookbook, which has sample code for various scenarios.

Those following the evolution of .NET will also enjoy a new document from the team called .Net Runtime Form Factors. Microsoft .NET Core architect Jan Kotas and principal program manager Richard Lander laid out a roadmap for .NET 5.0 and explained the compromises Microsoft has made. "We strived for a clean redesign of the whole .NET runtime, first as the Redhawk project, then .NET Native, and finally as the open source CoreRT project," they said. "It allowed us to see that it is possible to build .NET runtime form-factors that have performance characteristics on par with statically compiled environments such as C++ or Golang." CoreRT is an experimental project to optimize .NET for native compilation.

Unfortunately it does not look likely that this will come about in the near future. The original intent was to replace the "established .NET runtime implementation in its entirety" but "this goal was proven to be unrealistic," they said. "Executing this endeavor would require slowing down the investment into the mainstream .NET runtime to a trickle … we consider that direction unacceptable."

Instead, Microsoft is bringing pieces from CoreRT back into .NET Core and .NET 5.0, improving performance but not to the extent that the original CoreRT project promised. If you have time on your hands, the implications are debated at length here. The implication is that Microsoft has abandoned some .NET dreams for the sake of "customer visible value," as Kotas and Lander put it. ®

More about


Send us news

Other stories you might like