Performance Improvements in .NET 7

For folks using NegotiateStream, dotnet/runtime#71280 from @filipnavara will also be very welcome (this comes as part of a larger effort, primarily in dotnet/runtime#71777 from @filipnavara and dotnet/runtime#70720 from @filipnavara, to expose the new NegotiateAuthentication class). It removes a significant amount of allocation from a typical NTLM handshake by reusing a buffer rather than reallocating a new buffer for each of multiple phases of the handshake:

JSON

System.Text.Json was introduced in .NET Core 3.0, and has seen a significant amount of investment in each release since. .NET 7 is no exception. New features in .NET 7 include support for customizing contracts, polymorphic serialization, support for required members, support for DateOnly / TimeOnly, support for IAsyncEnumerable and JsonDocument in source generation, and support for configuring MaxDepth in JsonWriterOptions. However, there have also been new features specifically focused on performance, and other changes about improving performance of JSON handling in a variety of scenarios.

One of the biggest performance pitfalls we’ve seen developers face with System.Text.Json has to do with how the library caches data. In order to achieve good serialization and deserialization performance when the source generator isn’t used, System.Text.Json uses reflection emit to generate custom code for reading/writing members of the types being processed. Instead of then having to pay reflection invoke costs on every access, the library incurs a much larger one-time cost per type to perform this code generation, but then all subsequent handling of these types is very fast… assuming the generated code is available for use. These generated handlers need to be stored somewhere, and the location that’s used for storing them is them is JsonSerializerOptions. The idea was intended to be that developers would instantiate an options instance once and pass it around to all of their serialization/deserialization calls; thus, state like these generated handlers could be cached on them. And that works well when developers follow the recommended model. But when they don’t, performance falls off a cliff, and hard. Instead of “just” paying for the reflection invoke costs, each use of a new JsonSerializerOptions ends up re-generating via reflection emit those handlers, skyrocketing the cost of serialization and deserialization. A super simple benchmark makes this obvious:

In .NET 7, this was fixed in dotnet/runtime#64646 (and subsequently tweaked in dotnet/runtime#66248) by adding a global cache of the type information separate from the options instances. A JsonSerializerOptions still has a cache, but when new handlers are generated via reflection emit, those are also cached at the global level (with appropriate removal when no longer used in order to avoid unbounded leaks).

As can be seen here, it’s still more expensive to create a new JsonSerializerOptions instance on each call, and the recommended approach is “don’t do that.” But if someone does do it, in this example they’re only paying 3.6x the cost rather than 621x the cost, a huge improvement. dotnet/runtime#61434 also now exposes the JsonSerializerOptions.Default instance that’s used by default if no options are explicitly provided.

Another change to JsonSerializer came in dotnet/runtime#72510, which slightly improved the performance of serialization when using the source generator. The source generator emits helpers for performing the serialization/deserialization work, and these are then invoked by JsonSerializer via delegates (as part of abstracting away all the different implementation strategies for how to get and set members on the types being serialized and deserialized). Previously, these helpers were being emitted as static methods, which in turn meant that the delegates were being created to static methods. Delegates to instance methods are a bit faster to invoke than delegates to static methods, so this PR made a simple few-line change for the source generator to emit these as instance methods instead.

Yet another for JsonSerializer comes in dotnet/runtime#73338, which improves allocation with how it utilizes Utf8JsonWriter. Utf8JsonWriter is a class, and every time JsonSerializer would write out JSON, it would allocate a new Utf8JsonWriter instance. In turn, Utf8JsonWriter needs something to write to, and although the serializer was using an IBufferWriter implementation that pooled the underlying byte[] instances employed, the implementation of IBufferWriter itself is a class that JsonSerializer would allocate. A typical Serialize call would then end up allocating a few extra objects and an extra couple of hundred bytes just for these helper data structures. To address that, this PR takes advantage of [ThreadStatic], which can be put onto static fields to make them per-thread rather than per-process. From whatever thread is performing the (synchronous) Serialize operation, it then ensures the current thread has a Utf8JsonWriter and IBufferWriter instance it can use, and uses them; for the most part this is straightforward, but it needs to ensure that the serialization operation itself doesn’t try to recursively serialize, in which case these objects could end up being used erroneously while already in use. It also needs to make sure that the pooled IBufferWriter doesn’t hold on to any of its byte[]s while it’s not being used. That instance gets its arrays from ArrayPool, and we want those arrays to be usable in the meantime by anyone else making use of the pool, not sequestered off in this cached IBufferWriter implementation. This optimization is also only really meaningful for small object graphs being serialized, and only applies to the synchronous operations (asynchronous operations would require a more complicated pooling mechanism, since the operation isn’t tied to a specific thread, and the overhead of such complication would likely outweigh the modest gain this optimization provides).

Utf8JsonWriter and Utf8JsonReader also saw several improvements directly. dotnet/runtime#69580 adds a few new performance-focused members, the ValueIsEscaped property (which exposes already tracked information and enables consumers to avoid the expense of re-checking) and the CopyString method (which provides a non-allocating mechanism to get access to a string value from the reader). It then also uses the added support internally to speed up certain operations on Utf8JsonReader. And dotnet/runtime#63863, dotnet/runtime#71534, and dotnet/runtime#61746 fix how some exception checks and throws were being handled so as to not slow down the non-exceptional fast paths.

XML

System.Xml is used by a huge number of applications and services, but ever since JSON hit the scene and has been all the rage, XML has taken a back seat and thus hasn’t seen a lot of investment from either a functionality or performance perspective. Thankfully, System.Xml gets a bit of performance love in .NET 7, in particular around reducing allocation on some commonly used code paths.

Sometimes a performance fix is as easy as changing a single number. That’s the case with dotnet/runtime#63459 from @chrisdcmoore, which addresses a long-standing issue with the asynchronous methods on the popular XmlReader. When XmlReader was originally written, whoever developed it chose a fairly common buffer size to be used for read operations, namely 4K or 8K chars depending on various conditions. When XmlReader later gained asynchronous reading functionality, for whatever reason a much, much larger buffer size of 64K chars was selected (presumably in hopes of minimizing the number of asynchronous operations that would need to be employed, but the actual rationale is lost to history). A key problem with such a buffer size, beyond it leading to a lot of allocation, is the allocation it produces typically ends up on the Large Object Heap (LOH). By default, under the expectation that really large objects are long-lived, objects greater than 85K bytes are allocated into the LOH, which is treated as part of Gen 2, and that makes such allocation if not long-lived even more expensive in terms of overall impact on the system. Well, 64K chars is 128K bytes, which puts it squarely above that threshold. This PR lowers the size from 64K chars to 32K chars, putting it below the threshold (and generally reducing allocation pressure, how much memory needs to be zero’d, etc). While it’s still a very large allocation, and in the future we could look at pooling the buffer or employing a smaller one (e.g. no different from what’s done for the synchronous APIs), this simple one-number change alone makes a substantial difference for shorter input documents (while not perceivably negatively impacting larger ones).

XmlReader and XmlWriter saw other allocation-related improvements as well. dotnet/runtime#60076 from @kronic improved the ReadOnlyTernaryTree internal type that’s used when XmlOutputMethod.Html is specified in the XmlWriterSettings. This included using a ReadOnlySpan initialized from an RVA static instead of a large byte[] array that would need to be allocated. And dotnet/runtime#60057 from @kronic, which converted ~400 string creations in the System.Private.Xml assembly to use interpolated strings. Many of these cases were stylistic, converting something like string1 + “:” + string2 into $”{string1}:{string2}”; I say stylistic here because the C# compiler will generate the exact same code for both of those, a call to string.Concat(string1, “:”, string2), given that there’s a Concat overload that accepts three strings. However, some of the changes do impact allocation. For example, the private XmlTextWriter.GeneratePrefix method had the code:

where _top and temp are both ints. This will result in allocating two temporary strings and then concatenating those with the two constant strings. Instead, the PR changed it to:

which while shorter is also more efficient, avoiding the intermediate string allocations, as the custom interpolated string handler used by string.Create will format those into a pooled buffer rather than allocating intermediate temporaries.

XmlSerializer is also quite popular and also gets a (small) allocation reduction, in particular for deserialization. XmlSerializer has two modes for generating serialization/deserialization routines: using reflection emit to dynamically generate IL at run-time that are tuned to the specific shape of the types being serialized/deserialized, and the XML Serializer Generator Tool (sgen), which generates a .dll containing the same support, just ahead-of-time (a sort-of precursor to the Roslyn source generators we love today). In both cases, when deserializing, the generated code wants to track which properties of the object being deserialized have already been set, and to do that, it uses a bool[] as a bit array. Every time an object is deserialized, it allocates a bool[] with enough elements to track every member of the type. But in common usage, the vast majority of types being deserialized only have a relatively small number of properties, which means we can easily use stack memory to track this information rather than heap memory. That’s what dotnet/runtime#66914 does. It updates both of the code generators to stackalloc into a Span for less than or equal to 32 values, and otherwise fall back to the old approach of heap-allocating the bool[] (which can also then be stored into a Span so that the subsequent code paths simply use a span instead of an array). You can see this quite easily in the .NET Object Allocation Tracking tool in Visual Studio. For this console app (which, as an aside, shows how lovely the new raw string literals feature in C# is for working with XML):

Here’s what I see when I run this under .NET 6:

We’re running a thousand deserializations, each of which will deserialize 10 Release instances, and so we expect to see 10,000 Release objects being allocated, which we do… but we also see 10,000 bool[] being allocated. Now with .NET 7 (note the distinct lack of the per-object bool[]):

Other allocation reduction went into the creation of the serializer/deserializer itself, such as with dotnet/runtime#68738 avoiding allocating strings to escape text that didn’t actually need escaping, dotnet/runtime#66915 using stack allocation for building up small text instead of using a StringBuilder, dotnet/runtime#66797 avoiding delegate and closure allocations in accessing the cache of serializers previously created, dotnet/runtime#67001 from @TrayanZapryanov caching an array used with string.Split, and dotnet/runtime#67002 from @TrayanZapryanov that changed some parsing code to avoid a string.ToCharArray invocation.

For folks using XML schema, dotnet/runtime#66908 replaces some Hashtables in the implementation where those collections were storing ints as the value. Given that Hashtable is a non-generic collection, every one of those ints was getting boxed, resulting in unnecessary allocation overhead; these were fixed by replacing these Hashtables with Dictionary<..., int> instances. (As an aside, this is a fairly common performance-focused replacement to do, but you need to be careful as Hashtable has a few behavioral differences from Dictionary<,>; beyond the obvious difference of Hashtable returning null from its indexer when a key isn’t found and Dictionary<,> throwing in that same condition, Hashtable is thread-safe for use with not only multiple readers but multiple readers concurrent with a single writer, and Dictionary<,> is not.) dotnet/runtime#67045 reduces allocation of XmlQualifiedName instances in the implementation of XsdBuilder.ProcessElement and XsdBuilder.ProcessAttribute. And dotnet/runtime#64868 from @TrayanZapryanov uses stack-based memory and pooling to avoid temporary string allocation in the implementation of the internal XsdDateTime and XsdDuration types, which are used by the public XmlConvert.

XML pops up in other areas as well, as in the XmlWriterTraceListener type. While the System.Diagnostics.Trace type isn’t the recommended tracing mechanism for new code, it’s widely used in existing applications, and XmlWriterTraceListener let’s you plug in to that mechanism to write out XML logs for traced information. dotnet/runtime#66762 avoids a bunch of string allocation occurring as part of this tracing, by formatting much of the header information into a span and then writing that out rather than ToString()‘ing each individual piece of data.

Cryptography

Some fairly significant new features came to System.Security.Cryptography in .NET 7, including the support necessary to enable the previously discussed OCSP stapling and support for building certificate revocation lists, but there was also a fair amount of effort put into making existing support faster and more lightweight.

One fairly substantial change in .NET 7 is split across dotnet/runtime#61025, dotnet/runtime#61137, and dotnet/runtime#64307. These PRs don’t change any code materially, but instead consolidate all of the various cryptography-related assemblies in the core libraries into a single System.Security.Cryptography assembly. When .NET Core was first envisioned, a goal was to make it extremely modular, and large swaths of code were teased apart to create many smaller assemblies. For example, cryptographic functionality was split between System.Security.Cryptography.Algorithms.dll, System.Security.Cryptography.Cng.dll, System.Security.Cryptography.Csp.dll, System.Security.Cryptography.Encoding.dll, System.Security.Cryptography.OpenSsl.dll, System.Security.Cryptography.Primitives.dll, and System.Security.Cryptography.X509Certificates.dll. You can see this if you look in your shared framework folder for a previous release, e.g. here’s mine for .NET 6:

These PRs move all of that code into a single System.Security.Cryptography.dll assembly. This has several benefits. First, crypto is used in a huge number of applications, and most apps would end up requiring multiple (or even most) of these assemblies. Every assembly that’s loaded adds overhead. Second, a variety of helper files had to be compiled into each assembly, leading to overall larger amount of compiled code to be distributed. And third, we weren’t able to implement everything as optimal as we’d have otherwise liked due to functionality in one assembly not exposed to another (and we avoid using InternalsVisibleTo as it hampers maintainability and impedes other analysis and optimizations). Now in .NET 7, the shared framework looks more like this:

Interesting, you still see a bunch of assemblies there, but all except for System.Security.Cryptography.dll are tiny; that’s because these are simple facades. Because we need to support binaries built for .NET 6 and earlier running on .NET 7, we need to be able to handle binaries that refer to types in these assemblies, but in .NET 7, those types actually live in System.Security.Cryptography.dll. .NET provides a solution for this in the form of the [TypeForwardedTo(…)] attribute, which enables one assembly to say “hey, if you’re looking for type X, it now lives over there.” And if you crack open one of these assemblies in a tool like ILSpy, you can see they’re essentially empty except for a bunch of these attributes:

In addition to the startup and maintenance wins this provides, this has also enabled further subsequent optimization. For example, there’s a lot of object cloning that goes on in the innards of this library. Various objects are used to wrap native handles to OS cryptographic resources, and to handle lifetime semantics and ownership appropriately, there are many cases where a native handle is duplicated and then wrapped in one or more new managed objects. In some cases, however, the original resource is then destroyed because it’s no longer needed, and the whole operation could have been made more efficient if the original resource just had its ownership transferred to the new objects rather than being duplicated and destroyed. This kind of ownership transfer typically is hard to do between assemblies as it generally requires public API that’s not focused on such usage patterns, but with internals access, this can be overcome. dotnet/runtime#72120 does this, for example, to reduce allocation of various resources inside the RSACng, DSACng, ECDsaCng, and ECDiffieHellmanCng public types.

In terms of actual code improvements, there are many. One category of improvements is around “one-shot” operations. With many forms of data processing, all of the data needn’t be processed in one operation. A block of data can be processed, then another, then another, until finally there’s no more data to be processed. In such usage, there’s often some kind of state carried over from the processing of one block to the processing of the next, and then the processing of the last block is special as it needn’t carry over anything and instead needs to perform whatever work is required to end the whole operation, e.g. outputting any final footer or checksum that might be required as part of the format. Thus, APIs that are able to handle arbitrary number of blocks of data are often a bit more expensive in one way, shape, or form than APIs that only support a single input; this latter category is known as “one shot” operations, because they do everything in “one shot.” In some cases, one-shot operations can be significantly cheaper, and in other cases they merely avoid some allocations that would have been necessary to transfer state from the processing of one block of data to the next. dotnet/runtime#58270 from @vcsjones and dotnet/runtime#65725 from @vcsjones both improved the performance of various one-shot operations on “symmetric” cryptograhic algorithms (algorithms that use the same key information to both encrypt and decrypt), like AES. The former does so by refactoring the implementations to avoid some reset work that’s not necessary in the case of one-shots because the relevant state is about to go away, anyway, and that in turns also allows the implementation to store less of certain kinds of state. The latter does so for decryption one-shots by decrypting directly into the destination buffer whenever possible, using stack space if possible when going directly into the user’s buffer isn’t feasible, etc.

In addition to making one-shots lighterweight, other PRs have then used these one-shot operations in more places in order to simplify their code and benefit from the increased performance, e.g. dotnet/runtime#70639 from @vcsjones, dotnet/runtime#70857 from @vcsjones, dotnet/runtime#64005 from @vcsjones, and dotnet/runtime#64174 from @vcsjones.

There’s also a large number of PRs that have focused on removing allocations from around the crypto stack:

• Stack allocation. As has been seen in many other PRs referenced throughout this post, using stackalloc is a very effective way to get rid of array allocations in many situations. It’s used effectively in multiple crypto PRs to avoid either temporary or pooled array allocations, such as in dotnet/runtime#64584 from @vcsjones, dotnet/runtime#69831 from @vcsjones, dotnet/runtime#70173 from @vcsjones, dotnet/runtime#69812 from @vcsjones, and dotnet/runtime#69448 from @vcsjones. Sometimes this is used when calling an API that has multiple overloads, including one taking an array and one taking a span. Othertimes it’s used with P/Invokes that often just pass out a small amount of data. Sometimes it’s used to avoid temporary array allocations, and sometimes it’s used in places where pooling was used previously, but the data is often small enough to avoid even the overheads of pooling.
• Avoiding double copies. Most of the crypto APIs that accept byte[]s and store them end up making defensive copies of those arrays rather than storing the original. This is fairly common throughout .NET, but it’s especially common in the crypto stack, where the ability to trust the data is as you expect it (and validate it) is paramount. In some cases, though, code ends up allocating a temporary byte[] just to pass data into one of these APIs that copies and re-allocates, anyway. dotnet/runtime#71102 from @vcsjones, dotnet/runtime#69024 from @vcsjones, dotnet/runtime#71015 from @vcsjones, and dotnet/runtime#69534 from @vcsjones deal with that duplication in some cases by extracting a span to the original data instead of creating a temporary byte[]; when that span is passed into the target API, the target API still makes a copy, but we’ve avoided the first one and thus cut the array allocation for these operations effectively in half. dotnet/runtime#71888 from @vcsjones is a variation on this theme, improving the internals of Rfc2898DeriveBytes to supports spans such that its constructors that accept spans can then do the more efficient thing.
• Replacing O(1) data structures. O(1) lookup data structures like Dictionary<,> and HashSet<> are the lifeblood of most applications and services, but sometimes algorithmic complexity is misleading. Yes, these provide very efficient searching, but there’s still overhead associated with computing a hash code, mapping that hash code to a location in the data structure, and so on. If there’s only ever a handful of items (i.e. the N in the complexity is really, really small), it can be much faster to just do a linear search, and if N is sufficiently small, a data structure may not even be needed at all: the search can just be open-coded as a waterfall of if/elseif/else constructs. That’s the case in a PR like dotnet/runtime#71341 from @vcsjones, where the 99.999% case involves just five strings (names of hash algorithms); it’s cheaper to just compare against each than it is do a HashSet<>.Contains, especially since the JIT now unrolls and vectorizes the comparison against the constant string names.
• Simply avoiding unnecessary work. The best optimizations are ones where you simply stop doing work you don’t have to do. dotnet/runtime#68553 from @vcsjones is a good example of this. This code was performing a hash of some data in order to determine the length of resulting hashes for that particular configuration, but we actually know ahead of time exactly how long a hash for a given algorithm is going to be, and we already have in this code a cascading if/elseif/else that’s checking for each known algorithm, so we can instead just hardcode the length for each. dotnet/runtime#70589 from @vcsjones is another good example, in the same spirit of the ownership transfer example mentioned earlier (but this one didn’t previously span assembly boundaries). Rather than in several places taking an X509Extension, serializing it to a byte[], and passing that temporary byte[] to something else that in turn makes a defensive copy, we can instead provide an internal pathway for ownership transfer, bypassing all of the middle stages. Another good one is dotnet/runtime#70618 from @vcsjones, as it’s an example of how it pays to really understand your dependencies. The implementation of symmetric encryption on macOS uses the CommonCrypto library. One of the functions it exposes is CCCryptorFinal, which is used at the end of the encryption/decryption process. However, there are several cases called out in the docs where it’s unnecessary (“superfluous,” according to the docs), and so our dutifully calling it even in those situations is wasteful. The fix? Stop doing unnecessary work.
• New APIs. A bunch of new APIs were introduced for cryptography in .NET 7. Most are focused on easing scenarios that were difficult to do correctly before, like dotnet/runtime#66509 from @vcsjones that provides an X500DistinguishedNameBuilder. But some are focused squarely on performance. dotnet/runtime#57835 from @vcsjones, for example, exposes a new RawDataMemory property on X509Certificate2. Whereas the existing RawData property returns a new byte[] on every call (again a defensive copy to avoid having to deal with the possiblity that the consumer mucked with the raw data), this new RawDataMemory returns a ReadOnlyMemory around the internal byte[]. Since the only way to access and mutate that underlying byte[] via a ReadOnlyMemory is via unsafe interop code (namely via the System.Runtime.InteropServices.MemoryMarshal type), it doesn’t create a defensive copy and enables accessing this data freely without additional allocation.

Diagnostics

Let’s turn our attention to System.Diagnostics, which encompasses types ranging from process management to tracing.

The Process class is used for a variety of purposes, including querying information about running processes, interacting with other processes (e.g. being notified of their exiting), and launching processes. The performance of querying for information in particular had some notable improvements in .NET 7. Process provides several APIs for querying for process information, one of the most common being Process.GetProcessesByName: apps that know the name of the process they’re interested in can pass that to GetProcessesByName and get back a Process[] containing a Process for each. It turns out that previous releases of .NET were loading the full information (e.g. all of its threads) about every Process on the machine in order to filter down to just those with the target name. dotnet/runtime#68705 fixes that by only loading the name for a process rather than all of the information for it. While this helps a bit with throughput, it helps a ton with allocation:

Accessing various pieces of information from a Process has also improved. If you load a Process object via the Process.GetProcesses or Process.GetProcessesByName methods, by design they load all information about the Process being retrieved; internally their state will be populated such that subsequent accesses to members of the Process instance will be very fast. But, if you access a Process via Process.GetProcessById or Process.GetCurrentProcess (which is effectively GetProcessById for the current process’ id), no information other than the process’ ID is prepopulated, and the state for the Process instance is queried on-demand. In most cases, accessing a single member of one of those lazy-loaded Process instances triggers loading all of the data for it, as the information is all available as part of the same native operation, e.g. on Windows using NtQuerySystemInformation and on Linux reading from /proc/pid/stat and /proc/pid/status. But in some cases we can be more fine-grained about it, using APIs that serve up a subset of the data much more quickly. dotnet/runtime#59672 from @SteveDunn provides one such optimization, using the QueryFullProcessImageName on Windows to read the process name in response to Process.ProcessName being used. If all you care about reading is the process’ name, it’s a huge boost in throughput, and even if you subsequently go on to read additional state from the Process and force it to load everything else, accessing the process name is so fast that it doesn’t add meaningful overhead to the all-up operation. This is visible in this benchmark:

Interestingly, this PR had a small deficiency we didn’t initially catch, which is that the QueryFullProcessImageName API we switched to didn’t work in the case of elevated/privileged processes. To accomodate those, dotnet/runtime#70073 from @schuettecarsten updated the code to keep both the new and old implementations, starting with the new one and then only falling back to the old if operating on an incompatible process.

Several additional PRs helped out the Process class. When launching processes with Process.Start on Unix, the implementation was using Encoding.UTF8.GetBytes as part of argument handling, resulting in a temporary array being allocated per argument; dotnet/runtime#71279 removes that per-argument allocation, instead using Encoding.UTF8.GetByteCount to determine how large a space is needed and then using the Encoding.UTF8.GetBytes overload that accepts a span to encode directly into the native memory already being allocated. dotnet/runtime#71136 simplifies and streamlines the code involved in getting the “short name” of a process on Windows for use in comparing process names. And dotnet/runtime#45690 replaces a custom cache with use of ArrayPool in the Windows implementation of getting all process information, enabling effective reuse of the array that ends up being used rather than having it sequestered off in the Process implementation forever.

Another area of performance investment has been in DiagnosticSource, and in particular around enumerating through data from Activity instances. This work translates into faster integration and interoperability via OpenTelemetry, in order to be able to export data from .NET Activity information faster. dotnet/runtime#67012 from @CodeBlanch, for example, improved the performance of the internal DiagLinkedList.DiagEnumerator type that’s the enumerator returned when enumerating Activity.Links and Activity.Events by avoiding a copy of each T value:

o) => ActivitySamplingResult.AllDataAndRecorded }); _activity = activitySource.StartActivity( “TestActivity”, ActivityKind.Internal, parentContext: default, links: Enumerable.Range(0, 1024).Select(_ => new ActivityLink(default)).ToArray()); _activity.Stop(); } [Benchmark(Baseline = true)] public ActivityLink EnumerateActivityLinks() { ActivityLink last = default; foreach (ActivityLink link in _activity.Links) last = link; return last; }

Method	Runtime	Mean	Ratio	Allocated	Alloc Ratio
EnumerateActivityLinks	.NET 6.0	19.62 us	1.00	64 B	1.00
EnumerateActivityLinks	.NET 7.0	13.72 us	0.70	32 B	0.50

Then dotnet/runtime#67920 from @CodeBlanch and dotnet/runtime#68933 from @CodeBlanch added new EnumerateTagObjects, EnumerateEvents, and EnumerateLinks enumeration methods that return a struct-based enumerator that has a ref T-returning Current to avoid yet another layer of copy.

private readonly Activity _activity; public Program() { using ActivitySource activitySource = new ActivitySource(“Perf7Source”); ActivitySource.AddActivityListener(new ActivityListener { ShouldListenTo = s => s == activitySource, Sample = (ref ActivityCreationOptions o) => ActivitySamplingResult.AllDataAndRecorded }); _activity = activitySource.StartActivity( “TestActivity”, ActivityKind.Internal, parentContext: default, links: Enumerable.Range(0, 1024).Select(_ => new ActivityLink(default)).ToArray()); _activity.Stop(); } [Benchmark(Baseline = true)] public ActivityLink EnumerateActivityLinks_Old() { ActivityLink last = default; foreach (ActivityLink link in _activity.Links) last = link; return last; } [Benchmark] public ActivityLink EnumerateActivityLinks_New() { ActivityLink last = default; foreach (ActivityLink link in _activity.EnumerateLinks()) last = link; return last; }

Method	Mean	Ratio	Allocated	Alloc Ratio
EnumerateActivityLinks_Old	13.655 us	1.00	32 B	1.00
EnumerateActivityLinks_New	2.380 us	0.17	–	0.00

Of course, when it comes to diagnostics, anyone who’s ever done anything with regards to timing and measurements is likely familiar with good ol’ Stopwatch. Stopwatch is a simple type that’s very handy for getting precise measurements and is thus used all over the place. But for folks that are really cost-sensitive, the fact that Stopwatch is a class can be prohibitive, e.g. writing:

Stopwatch sw = Stopwatch.StartNew(); …; TimeSpan elapsed = sw.Elapsed;

is easy, but allocates a new object just to measure. To address this, Stopwatch has for years exposed the static GetTimestamp() method which avoids that allocation, but consuming and translating the resulting long value is complicated, requiring a formula involving using Stopwatch.Frequency and TimeSpan.TicksPerSecond in the right incantation. To make this pattern easy, dotnet/runtime#66372 adds a static GetElapsedTime method that handles that conversion, such that someone who wants that last mile of performance can write:

long timestamp = Stopwatch.GetTimestamp(); … TimeSpan elapsed = Stopwatch.GetElapsedTime(timestamp);

which avoids the allocation and saves a few cycles:

[Benchmark(Baseline = true)] public TimeSpan Old() { Stopwatch sw = Stopwatch.StartNew(); return sw.Elapsed; } [Benchmark] public TimeSpan New() { long timestamp = Stopwatch.GetTimestamp(); return Stopwatch.GetElapsedTime(timestamp); }

Method	Mean	Ratio	Allocated	Alloc Ratio
Old	32.90 ns	1.00	40 B	1.00
New	26.30 ns	0.80	–	0.00

Exceptions

It might be odd to see the subject of “exceptions” in a post on performance improvements. After all, exceptions are by their very nature meant to be “exceptional” (in the “rare” sense), and thus wouldn’t typically contribute to fast-path performance. Which is a good thing, because fast-paths that throw exceptions in the common case are no longer fast: throwing exceptions is quite expensive.

Instead, one of the things we do concern ourselves with is how to minimize the impact of checking for exceptional conditions: the actual exception throwing may be unexpected and slow, but it’s super common to need to check for those unexpected conditions, and that checking should be very fast. We also want such checking to minimally impact binary size, especially if we’re going to have many such checks all over the place, in generic code for which we end up with many copies due to generic specialization, in functions that might be inlined, and so on. Further, we don’t want such checks to impede other optimizations; for example, if I have a small function that wants to do some argument validation and would otherwise be inlineable, I likely don’t want the presence of exception throwing to invalidate the possibility of inlining.

Because of all of that, high-performance libraries often come up with custom “throw helpers” they use to achieve their goals. There are a variety of patterns for this. Sometimes a library will just define its own static method that handles constructing and throwing an exception, and then call sites do the condition check and delegate to the method if throwing is needed:

if (arg is null) ThrowArgumentNullException(nameof(arg)); … [DoesNotReturn] private static void ThrowArgumentNullException(string arg) => throw new ArgumentNullException(arg);

This keeps the IL associated with the throwing out of the calling function, minimizing the impact of the throw. That’s particularly valuable when additional work is needed to construct the exception, e.g.

private static void ThrowArgumentNullException(string arg) => throw new ArgumentNullException(arg, SR.SomeResourceMessage);

Other times, libraries will encapsulate both the checking and throwing. This is exactly what the ArgumentNullException.ThrowIfNull method that was added in .NET 6 does:

public static void ThrowIfNull([NotNull] object? argument, [CallerArgumentExpression(“argument”)] string? paramName = null) { if (argument is null) Throw(paramName); } [DoesNotReturn] internal static void Throw(string? paramName) => throw new ArgumentNullException(paramName);

With that, callers benefit from the concise call site:

public void M(string arg) { ArgumentNullException.ThrowIfNull(arg); … }

the IL remains concise, and the assembly generated for the JIT will include the streamlined condition check from the inlined ThrowIfNull but won’t inline the Throw helper, resulting in effectively the same code as if you’d written the previously shown manual version with ThrowArgumentNullException yourself. Nice.

Whenever we introduce new public APIs in .NET, I’m particularly keen on seeing them used as widely as possible. Doing so serves multiple purposes, including helping to validate that the new API is usable and fully addresses the intended scenarios, and including the rest of the codebase benefiting from whatever that API is meant to provide, whether it be a performance improvement or just a reduction in routinely written code. In the case of ArgumentNullException.ThrowIfNull, however, I purposefully put on the brakes. We used it in .NET 6 in several dozen call sites, but primarily just in place of custom ThrowIfNull-like helpers that had sprung up in various libraries around the runtime, effectively deduplicating them. What we didn’t do, however, was replace the literally thousands of null checks we have with calls to ArgumentNullException.ThrowIfNull. Why? Because the new !! C# feature was right around the corner, destined for C# 11.

For those unaware, the !! feature enabled putting !! onto parameter names in member signatures, e.g.

public void Process(string name!!) { … }

The C# compiler then compiled that as equivalent to:

public void Process(string name) { ArgumentNullException.ThrowIfNull(name); }

(albeit using its own ThrowIfNull helper injected as internal into the assembly). Armed with the new feature, dotnet/runtime#64720 and dotnet/runtime#65108 rolled out use of !! across dotnet/runtime, replacing ~25,000 lines of code with ~5000 lines that used !!. But, what’s the line from Kung Fu Panda, “One often meets his destiny on the road he takes to avoid it”? The presence of that initial PR kicked off an unprecedented debate about the !! feature, with many folks liking the concept but a myriad of different opinions about exactly how it should be exposed, and in the end, the only common ground was to cut the feature. In response, dotnet/runtime#68178 undid all usage of !!, replacing most of it with ArgumentNullException.ThrowIfNull. There are now ~5000 uses of ArgumentNullException.ThrowIfNull across dotnet/runtime, making it one of our most popular APIs internally. Interestingly, while we expected a peanut-buttery effect of slight perf improvements in many places, our performance auto-analysis system flagged several performance improvements (e.g. dotnet/perf-autofiling-issues#3531) as stemming from these changes, in particular because it enabled the JIT’s inlining heuristics to flag more methods for inlining.

With the success of ArgumentNullException.ThrowIfNull and along with its significant roll-out in .NET 7, .NET 7 also sees the introduction of several more such throw helpers. dotnet/runtime#61633, for example, adds an overload of ArgumentNullException.ThrowIfNull that works with pointers. dotnet/runtime#64357 adds the new ArgumentException.ThrowIfNullOrEmpty helper as well as using it in several hundred places. And dotnet/runtime#58684 from @Bibletoon adds the new ObjectDisposedException.ThrowIf helper (tweaked by dotnet/runtime#71544 to help ensure it’s inlineable), which is then used at over a hundred additional call sites by dotnet/runtime#71546.

Registry

On Windows, the Registry is a database provided by the OS for applications and the system itself to load and store configuration settings. Practically every application accesses the registry. I just tried a simple console app:

Console.WriteLine(“Hello, world”);

built it as release, and then ran the resulting .exe. That execution alone triggered 64 RegQueryValue operations (as visible via SysInternals’ Process Monitor tool). The core .NET libraries even access the registry for a variety of purposes, such as for gathering data for TimeZoneInfo, gathering data for various calendars like HijriCalendar and JapaneseCalendar, or for serving up environment variables as part of Environment.GetEnvironmentVariable(EnvironmentVariableTarget) with EnvironmentVariableTarget.User or EnvironmentVariableTarget.Machine.

It’s thus beneficial to streamline access to registry data on Windows, in particular for reducing overheads in startup paths where the registry is frequently accessed. dotnet/runtime#66918 does just that. Previously, calling RegistryKey.GetValue would make a call to RegQueryValueEx with a null buffer; this tells the RegQueryValueEx method that the caller wants to know how big a buffer is required in order to store the value for the key. The implementation would then allocate a buffer of the appropriate size and call RegQueryValueEx again, and for values that are to be returned as strings, would then allocate a string based on the data in that buffer. This PR instead recognizes that the vast majority of data returned from calls to the registry is relatively small. It starts with a stackalloc‘d buffer of 512 bytes, and uses that buffer as part of the initial call to RegQueryValueEx. If the buffer was sufficiently large, we no longer have to make a second system call to retrieve the actual data: we already got it. If the buffer was too small, we rent an ArrayPool buffer of sufficient size and use that pooled buffer for the subsequent RegQueryValueEx call. Except in situations where we actually need to return a byte[] array to the caller (e.g. the type of the key is REG_BINARY), this avoids the need for the allocated byte[]. And for keys that return strings (e.g. the type of the key is REG_SZ), previously the old implementation would have allocated a temporary char[] to use as the buffer passed to RegQueryValueEx, but we can instead just reinterpret cast (e.g. MemoryMarshal.Cast) the original buffer (whether a stackalloc‘d span or the rented buffer as a Span), and use that to construct the resulting string.

private static readonly RegistryKey s_netFramework = Registry.LocalMachine.OpenSubKey(@”SOFTWAREMicrosoft.NETFramework”); [Benchmark] public string RegSz() => (string)s_netFramework.GetValue(“InstallRoot”);

Method	Runtime	Mean	Ratio	Allocated	Alloc Ratio
RegSz	.NET 6.0	6.266 us	1.00	200 B	1.00
RegSz	.NET 7.0	3.182 us	0.51	96 B	0.48

Analyzers

The ability to easily plug custom code, whether for analyzers or source generators, into the Roslyn compiler is one of my favorite features in all of C#. It means the developers working on C# don’t need to be solely responsible for highlighting every possible thing you might want to diagnose in your code. Instead, library authors can write their own analyzers, ship them either in dedicated nuget packages or as side-by-side in nuget packages with APIs, and those analyzers augment the compiler’s own analysis to help developers write better code. We ship a large number of analyzer rules in the .NET SDK, many of which are focused on performance, and we augment that set with more and more analyzers every release. We also work to apply more and more of those rules against our own codebases in every release. .NET 7 is no exception.

One of my favorite new analyzers was added in dotnet/roslyn-analyzers#5594 from @NewellClark (and tweaked in dotnet/roslyn-analyzers#5972). In my .NET 6 performance post, I talked about some of the overheads possible when types aren’t sealed:

• Virtual calls are more expensive than regular non-virtual invocation and generally can’t be inlined, since the JIT doesn’t know what is the actual type of the instance and thus the actual target of the invocation (at least not without assistance from PGO). But if the JIT can see that a virtual method is being invoked on a sealed type, it can devirtualize the call and potentially even inline it.
• If a type check (e.g. something is typeof(SomeType)) is performed where SomeType is sealed, that check can be implemented along the lines of something is not null && something.GetType() == typeof(SomeType). In contrast, if SomeType is not sealed, the check is going to be more along the lines of CastHelpers.IsInstanceOfClass(typeof(SomeType), something), where IsInstanceOfClass is a non-trivial (and today non-inlined) call into a JIT helper method in Corelib that not only checks for null and for direct equality with the specified type, but also linearly walks the parent hierarchy of the type of the object being tested to see if it might derive from the specified type.
• Arrays in .NET are covariant, which means if types B and C both derive from type A, you can have a variable typed as A[] that’s storing a B[]. Since C derives from A, it’s valid to treat a C as an A, but if the A[] is actually a B[], storing a C into that array would mean storing a C into a B[], which is invalid. Thus, every time you store an object reference into an array of reference types, additional validation may need to be performed to ensure the reference being written is compatible with the concrete type of the array in question. But, if A in this example were sealed, nothing could derive from it, so storing objects into it doesn’t require such covariance checks.
• Spans shift this covariance check to their constructor; rather than performing the covariance check on every write into the array, the check is performed when a span is being constructed from an array, such that if you try to create a new Span(bArray), the ctor will throw an exception. If A is sealed, the JIT is able to elide such a check as well.

It effectively would be impossible for an analyzer to be able to safely recommend sealing public types. After all, it has no knowledge of the type’s purpose, how it’s intended to be used, and whether anyone outside of the assembly containing the type actually derives from it. But internal and private types are another story. An analyzer can actually see every possible type that could be deriving from a private type, since the analyzer has access to the whole compilation unit containing that type, and it needn’t worry about compatibility because anything that could derive from such a type necessarily must also be non-public and would be recompiled right along with the base type. Further, with the exception of assemblies annotated as InternalsVisibleTo, an analyzer can have the same insight into internal types. Thus, this PR adds CA1852, an analyzer that flags in non-InternalsVisibleTo assemblies all private and internal types that aren’t sealed and that have no types deriving from them and recommends they be sealed. (Due to some current limitations in the infrastructure around fixers and how this analyzer had to be written in order to be able to see all of the types in the assembly, the analyzer for CA1852 doesn’t show up in Visual Studio. It can, however, be applied using the dotnet format tool. And if you bump up the level of the rule from info to warning or error, it’ll show up as part of builds as well.)

In .NET 6, we sealed over 2300 types, but even with that, this analyzer ended up finding more to seal. dotnet/runtime#59941 from @NewellClark sealed another ~70 types, and dotnet/runtime#68268 which enabled the rule as an warning in dotnet/runtime (which builds with warnings-as-errors) sealed another ~100 types. As a larger example of the rule in use, ASP.NET hadn’t done much in the way of sealing types in previous releases, but with CA1852 now in the .NET SDK, dotnet/aspnetcore#41457 enabled the analyzer and sealed more than ~1100 types.

Another new analyzer, CA1854, was added in dotnet/roslyn-analyzers#4851 from @CollinAlpert and then enabled in dotnet/runtime#70157. This analyzer looks for the surprisingly common pattern where a Dictionary‘s ContainsKey is used to determine whether a dictionary contains a particular entry, and then if it does, the dictionary’s indexer is used to retrieve the value associated with the key, e.g.

if (_dictionary.ContainsKey(key)) { var value = _dictionary[key]; Use(value); }

Dictionary’s TryGetValue method already combines both of these operations, both looking up the key and retrieving its value if it exists, doing so as a single operation:

if (_dictionary.TryGetValue(key, out var value)) { Use(value); }

A benefit of this, in addition to arguably being simpler, is that it’s also faster. While Dictionary provides very fast lookups, and while the performance of those lookups has gotten faster over time, doing fast work is still more expensive than doing no work, and if we can do one lookup instead of two, that can result in a meaningful performance boost, in particular if it’s being performed on a fast path. And we can see from this simple benchmark that looks up a word in a dictionary that, for this operation, making distinct calls to ContainsKey and the indexer does indeed double the cost of using the dictionary, almost exactly:

private readonly Dictionary _counts = Regex.Matches( new HttpClient().GetStringAsync(“https://www.gutenberg.org/cache/epub/100/pg100.txt”).Result, @”bw+b”) .Cast() .GroupBy(word => word.Value, StringComparer.OrdinalIgnoreCase) .ToDictionary(word => word.Key, word => word.Count(), StringComparer.OrdinalIgnoreCase); private string _word = “the”; [Benchmark(Baseline = true)] public int Lookup1() { if (_counts.ContainsKey(_word)) { return _counts[_word]; } return -1; } [Benchmark] public int Lookup2() { if (_counts.TryGetValue(_word, out int count)) { return count; } return -1; }

Method	Mean	Ratio
Lookup1	28.20 ns	1.00
Lookup2	14.12 ns	0.50

Somewhat ironically, even as I write this example, the analyzer and its auto-fixer are helpfully trying to get me to change my benchmark code:

Similarly, dotnet/roslyn-analyzers#4836 from @chucker added CA1853, which looks for cases where a Remove call on a dictionary is guarded by a ContainsKey call. It seems it’s fairly natural for developers to only call Remove on a dictionary once they’re sure the dictionary contains the thing being removed; maybe they think Remove will throw an exception if the specified key doesn’t exist. However, Remove actually allows this as a first-class scenario, with its return Boolean value indicating whether the key was in the dictionary (and thus successfully removed) or not. An example of this comes from dotnet/runtime#68724, where CA1853 was enabled for dotnet/runtime. The EventPipeEventDispatcher type’s RemoveEventListener method had code like this:

if (m_subscriptions.ContainsKey(listener)) { m_subscriptions.Remove(listener); }

which the analyzer flagged and which it’s auto-fixer replaced with just:

m_subscriptions.Remove(listener);

Nice and simple. And faster, since as with the TryGetValue case, this is now doing a single dictionary lookup rather than two.

Another nice analyzer added in dotnet/roslyn-analyzers#5907 and dotnet/roslyn-analyzers#5910 is CA1851, which looks for code that iterates through some kinds of enumerables multiple times. Enumerating an enumerator, whether directly or via helper methods like those in LINQ, can have non-trivial cost. Calling GetEnumerator typically allocates an enumerator object, and every item yielded typically involves two interface calls, one to MoveNext and one to Current. If something can be done via a single pass over the enumerable rather than multiple passes, that can save such costs. In some cases, seeing places this analyzer fires can also inspire changes that avoid any use of enumerators. For example, dotnet/runtime#67292 enabled CA1851 for dotnet/runtime, and in doing so, it fixed several diagnostics issued by the analyzer (even in a code base that’s already fairly stringent about enumerator and LINQ usage). As an example, this is a function in System.ComponentModel.Composition that was flagged by the analyzer:

private void InitializeTypeCatalog(IEnumerable types) { foreach (Type type in types) { if (type == null) { throw ExceptionBuilder.CreateContainsNullElement(nameof(types)); } else if (type.Assembly.ReflectionOnly) { throw new ArgumentException(SR.Format(SR.Argument_ElementReflectionOnlyType, nameof(types)), nameof(types)); } } _types = types.ToArray(); }

The method’s purpose is to convert the enumerable into an array to be stored, but also to validate that the contents are all non-null and non-“ReflectionOnly.” To achieve that, the method is first using a foreach to iterate through the enumerable, validating each element along the way, and then once it’s done so, it calls ToArray() to convert the enumerable into an array. There are multiple problems with this. First, it’s incurring the expense of interating through the enumerable twice, once for the foreach and once for the ToArray(), which internally needs to enumerate it if it can’t do something special like cast to ICollection and CopyTo the data out of it. Second, it’s possible the caller’s IEnumerable changes on each iteration, so any validation done in the first iteration isn’t actually ensuring there aren’t nulls in the resulting array, for example. Since the expectation of the method is that all inputs are valid and we don’t need to optimize for the failure cases, the better approach is to first call ToArray() and then validate the contents of that array, which is exactly what that PR fixes it to do:

private void InitializeTypeCatalog(IEnumerable types) { Type[] arr = types.ToArray(); foreach (Type type in arr) { if (type == null) { throw ExceptionBuilder.CreateContainsNullElement(nameof(types)); } if (type.Assembly.ReflectionOnly) { throw new ArgumentException(SR.Format(SR.Argument_ElementReflectionOnlyType, nameof(types)), nameof(types)); } } _types = arr; }

With that, we only ever iterate it once (and possibly 0 times if ToArray can special-case it, and bonus, we validate on the copy rather than on the mutable original.

Yet another helpful analyzer is the new CA1850 introduced in dotnet/roslyn-analyzers#4797 from @wzchua. It used to be that if you wanted to cryptographically hash some data in .NET, you would create an instance of a hash algorithm and call its ComputeHash method, e.g.

public byte[] Hash(byte[] data) { using (SHA256 h = SHA256.Create()) { return h.ComputeHash(data); } }

However, .NET 5 introduced new “one-shot” hashing methods, which obviates the need to create a new HashAlgorithm instance, providing a static method that performs the whole operation.

public byte[] Hash(byte[] data) { return SHA256.HashData(data); }

CA1850 finds occurrences of the former pattern and recommends changing them to the latter.

The result is not only simpler, it’s also faster:

private readonly byte[] _data = RandomNumberGenerator.GetBytes(128); [Benchmark(Baseline = true)] public byte[] Hash1() { using (SHA256 h = SHA256.Create()) { return h.ComputeHash(_data); } } [Benchmark] public byte[] Hash2() { return SHA256.HashData(_data); }

Method	Mean	Ratio	Allocated	Alloc Ratio
Hash1	1,212.9 ns	1.00	240 B	1.00
Hash2	950.8 ns	0.78	56 B	0.23

The .NET 7 SDK also includes new analyzers around [GeneratedRegex(…)] (dotnet/runtime#68976) and the already mentioned ones for LibraryImport, all of which help to move your code forwards to more modern patterns that have better performance characteristics.

This release also saw dotnet/runtime turn on a bunch of additional IDEXXXX code style rules and make a huge number of code changes in response. Most of the resulting changes are purely about simplifying the code, but in almost every case some portion of the changes also have a functional and performance impact.

Let’s start with IDE0200, which is about removing unnecessary lambdas. Consider a setup like this:

public class C { public void CallSite() => M(i => Work(i)); public void M(Action action) { } private static void Work(int value) { } }

Here we have a method CallSite that’s invoking a method M and passing a lambda to it. Method M accepts an Action, and the call site is passing a lambda that takes the supplied Int32 and passes it off to some static functionality. For this code, the C# compiler is going to generate something along the lines of this:

public class C { [CompilerGenerated] private sealed class <>c { public static readonly <>c <>9 = new <>c(); public static Action <>9__0_0; internal void b__0_0(int i) => Work(i); } public void CallSite() => M(<>c.<>9__0_0 ??= new Action(<>c.<>9.b__0_0)); public void M(Action action) { } private static void Work(int value) { } }

The most important aspect of this is that <>9__0_0 field the compiler emitted. That field is a cache for the delegate created in CallSite. The first time CallSite is invoked, it’ll allocate a new delegate for the lambda and store it into that field. For all subsequent invocations, however, it’ll find the field is non-null and will just reuse the same delegate. Thus, this lambda only ever results in a single allocation for the whole process (ignoring any race conditions on the initial lazy initialization such that multiple threads all racing to initialize the field might end up producing a few additional unnecessary allocations). It’s important to recognize this caching only happens because the lambda doesn’t access any instance state and doesn’t close over any locals; if it did either of those things, such caching wouldn’t happen. Secondarily, it’s interesting to note the pattern the compiler uses for the lambda itself. Note that generated b__0_0 method is generated as an instance method, and the call site refers to that method of a singleton instance that’s used to initialize a <>9 field. That’s done because delegates to static methods use something called a “shuffle thunk” to move arguments into the right place for the target method invocation, making delegates to statics ever so slightly more expensive to invoke than delegates to instance methods.

private Action _instance = new C().InstanceMethod; private Action _static = C.StaticMethod; [Benchmark(Baseline = true)] public void InvokeInstance() => _instance(); [Benchmark] public void InvokeStatic() => _static(); private sealed class C { public static void StaticMethod() { } public void InstanceMethod() { } }

Method	Mean	Ratio
InvokeInstance	0.8858 ns	1.00
InvokeStatic	1.3979 ns	1.58

So, the compiler is able to cache references to lambdas, great. What about method groups, i.e. where you just name the method directly? Previously, if changed my code to:

public class C { public void CallSite() => M(Work); public void M(Action action) { } private static void Work(int value) { } }

the compiler would generate the equivalent of:

public class C { public void CallSite() => M(new Action(Work)); public void M(Action action) { } private static void Work(int value) { } }

which has the unfortunate effect of allocating a new delegate on every invocation, even though we’re still dealing with the exact same static method. Thanks to dotnet/roslyn#58288 from @pawchen, the compiler will now generate the equivalent of:

public class C { [CompilerGenerated] private static class <>O { public static Action <0>__Work; } public void CallSite() => M(<>O.<0>__Work ??= new Action(Work)); public void M(Action action) { } private static void Work(int value) { } }

Note we again have a caching field that’s used to enable allocating the delegate once and caching it. That means that places where code was using a lambda to enable this caching can now switch back to the cleaner and simpler method group way of expressing the desired functionality. There is the interesting difference to be cognizant of that since we don’t have a lambda which required the compiler emitting a new method for, we’re still creating a delegate directly to the static method. However, the minor difference in thunk overhead is typically made up for by the fact that we don’t have a second method to invoke; in the common case where the static helper being invoked isn’t inlinable (because it’s not super tiny, because it has exception handling, etc.), we previously would have incurred the cost of the delegate invocation plus the non-inlinable method call, and now we just have the cost of an ever-so-slightly more expensive delegate invocation; on the whole, it’s typically a wash.

And that brings us to IDE0200, which recognizes lambda expressions that can be removed. dotnet/runtime#71011 enabled the analyzer for dotnet/runtime, resulting in more than 100 call sites changing accordingly. However, IDE0200 does more than just this mostly stylistic change. It also recognizes some patterns that can make a more substantial impact. Consider this code that was changed as part of that PR:

Action disposeAction; IDisposable? disposable = null; … if (disposable != null) { disposeAction = () => disposable.Dispose(); }

That delegate closes over the disposable local, which means this method needs to allocate a display class. But IDE0200 recognizes that instead of closing over disposable, we can create the delegate directly to the Dispose method:

Action disposeAction; IDisposable? disposable = null; … if (disposable != null) { disposeAction = disposable.Dispose; }

We still get a delegate allocation, but we avoid the display class allocation, and as a bonus we save on the additional metadata required for the synthesized display class and method generated for the lambda.

IDE0020 is another good example of an analyzer that is primarily focused on making code cleaner, more maintainable, more modern, but that can also lead to removing overhead from many different places. The analyzer looks for code performing unnecessary duplicative casts and recommends using C# pattern matching syntax instead. For example, dotnet/runtime#70523 enabled the analyzer and switched more than 250 locations from code like:

if (value is SqlDouble) { SqlDouble i = (SqlDouble)value; return CompareTo(i); }

to instead be like:

if (value is SqlDouble i) { return CompareTo(i); }

In addition to being cleaner, this ends up saving a cast operation, which can add measurable overhead if the JIT is unable to remove it:

private object _value = new List(); [Benchmark(Baseline = true)] public List WithCast() { object value = _value; return value is List ? (List)value : null; } [Benchmark] public List WithPattern() { object value = _value; return value is List list ? list : null; }

Method	Mean	Ratio
WithCast	2.602 ns	1.00
WithPattern	1.886 ns	0.73

Then there’s IDE0031, which promotes using null propagation features of C#. This analyzer typically manifests as recommending changing snippets like:

return _value != null ? _value.Property : null;

into code that’s instead like:

return _value?.Property;

Nice, concise, and primarily about cleaning up the code and making it simpler and more maintainable by utilizing newer C# syntax. However, there is also a small performance advantage in some situations as well. For example, consider this snippet:

public class C { private C _value; public int? Get1() => _value != null ? _value.Prop : null; public int? Get2() => _value?.Prop; public int Prop => 42; }

The C# compiler lowers these expressions to the equivalent of this:

public Nullable Get1() { if (_value == null) return null; return _value.Prop; } public Nullable Get2() { C value = _value; if (value == null) return null; return value.Prop; }

for which the JIT then generates:

; Program.Get1() push rax mov rdx,[rcx+8] test rdx,rdx jne short M00_L00 xor eax,eax add rsp,8 ret M00_L00: cmp [rdx],dl mov dword ptr [rsp+4],2A mov byte ptr [rsp],1 mov rax,[rsp] add rsp,8 ret ; Total bytes of code 40 ; Program.Get2() push rax mov rax,[rcx+8] test rax,rax jne short M00_L00 xor eax,eax add rsp,8 ret M00_L00: mov dword ptr [rsp+4],2A mov byte ptr [rsp],1 mov rax,[rsp] add rsp,8 ret ; Total bytes of code 38

Note how the Get1 variant has an extra cmp instruction (cmp [rdx],dl) in the otherwise identical assembly to Get2 (other than register selection). That cmp instruction in Get1 is the JIT forcing a null check on the second read of _value prior to accessing its Prop, whereas in Get2 the null check against the local means the JIT doesn’t need to add an additional null check on the second use of the local, since nothing could have changed it. dotnet/runtime#70965 rolled out additional use of the null propagation operator via auto-fixing IDE0031, resulting in ~120 uses being improved.

Another interesting example is IDE0060, which finds unused parameters and recommends removing them. This was done for non-public members in System.Private.CoreLib in dotnet/runtime#63015. As with some of the other mentioned rules, it’s primarily about good hygiene. There can be some small additional cost associated with passing additional parameters (the overhead of reading the values at the call site, putting them into the right register or stack location, etc., and also the metadata size associated with the additional parameter information), but the larger benefit comes from auditing all of the cited violations and finding places where work is simply being performed unnecessarily. For example, that PR made some updates to the TimeZoneInfo type’s implementation for Unix. In that implementation is a TZif_ParseRaw method, which is used to extract some information from a time zone data file. Amongst many input and output parameters, it had out bool[] StandardTime, out bool[] GmtTime, which the implementation was dutifully filling in by allocating and populating new arrays for each. The call site for TZif_ParseRaw was then taking those arrays and feeding them into another method TZif_GenerateAdjustmentRules, which ignored them! Thus, not only was this PR able to remove those parameters from TZif_GenerateAdjustmentRules, it was able to update TZif_ParseRaw to no longer need to allocate and populate those arrays at all, which obviously yields a much larger gain.

One final example of peanut-buttery performance improvements from applying an analyzer comes from dotnet/runtime#70896 and dotnet/runtime#71361, which applied IDE0029 across dotnet/runtime. IDE0029 flags cases where null coalescing can be used, e.g. flagging:

return message != null ? message : string.Empty;

and recommending it be converted to:

return message ?? string.Empty;

As with some of the previous rules discussed, that in and of itself doesn’t make a meaningful performance improvement, and rather is about clarity and simplicity. However, in various cases it can. For example, the aforementioned PRs contained an example like:

null != foundColumns[i] ? foundColumns[i] : DBNull.Value;

which is rewritten to:

foundColumns[i] ?? DBNull.Value

This avoids an unnecessary re-access to an array. Or again from those PRs the expression:

entry.GetKey(_thisCollection) != null ? entry.GetKey(_thisCollection) : “key”

being changed to:

entry.GetKey(_thisCollection) ?? “key”

and avoiding an unnecessary table lookup.

What’s Next?

Whew! That was a lot. Congrats on getting through it all.

The next step is on you. Download the latest .NET 7 bits and take them for a spin. Upgrade your apps. Write and share your own benchmarks. Provide feedback, positive and critical. Find something you think can be better? Open an issue, or better yet, submit a PR with the fix. We’re excited to work with you to polish .NET 7 to be the best .NET release yet; meanwhile, we’re getting going on .NET 8

Until next time…

Happy coding!

Source

---

this site is a gnomie of the domain mym3verse.space

No Comments Yet

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Comment

Name

Email

Website

Save my name, email, and website in this browser for the next time I comment.

Post Comment

mym3verse

||| © mym3verse 2050