ladeak

Ref Returns

C# has recently introduced some new features (version <7.0) one of which it is ref returns. I will use this feature in this post to further improve the performance of the Parser created in my previous post.

To refresh the Parser class looked as follows:

public class Parser 
{
 public T Parse(ReadOnlySpan input, PropertySetter[] setters) where T : struct

ladeak

Deep Dive in Ref Returns

In the previous post I have used Ref returns to return some data. I noticed that with slight changes we get totally different code generated by the JIT, which is can have a good or bad effect on our code.

In this post, I will dig deep (with WinDbg) in the JIT generated code. As forefront: I am using 64 bit machine, .net core 2.1 and RyuJIT.

I created a sample benchmark to showcase. I have a Point struct with 2 integer properties. I benchmark setting the values on the struct in 3 different ways, I show related IL and machine code impacting performance.

The benchmark

ladeak

Null-coalescing Operator vs. Equals - Equals

I have been asked the following question over-and-over: which solution is the faster and better to use in the condition part of the if keyword, to branch based on a property which might be defined on a nullable reference type:

• to use the null-coalescing operator (??)
• or the equals operator (==)

To give some context let's assume that we branch our code based on a reference type's bool property:

public class SomeClass

ladeak

using System.Diagnostics;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;

namespace ConsoleApp2
{
    public class ActivityLogWriter : IActivityWriter
    {
        private readonly ILogger<ActivityLogWriter> _logger;

ladeak

using System.Diagnostics;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;

namespace ConsoleApp2
{
    public class ActivityLogWriter : IActivityWriter
    {
        private readonly ILogger<ActivityLogWriter> _logger;

ladeak

String Interpolation and StringBuilder in .NET6

In a previous post I have looked into what are the performance characteristics of creating interpolated string in .NET 5 and early previews of .NET 6. With .NET 6 preview 7 or better a new approach is used by the C# compiler with support from the BCL to build interpolated strings.

Fortunately the new way provides a faster approach for the most convenient ways for assembling strings, however it makes my previous post completely obsolete.

For details about the new way DefaultInterpolatedStringHandler builds strings, read: https://devblogs.microsoft.com/dotnet/string-interpolation-in-c-10-and-net-6/

Re-running the benchmarks from the previous post, shows much better memory usage:

ladeak

https://www.nerdfonts.com/font-downloads
CaskaydiaCode Nerd Font

ladeak

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.22000 Intel Core i5-1035G4 CPU 1.10GHz, 1 CPU, 8 logical and 4 physical cores .NET SDK=7.0.100-alpha.1.22053.1 [Host] : .NET 7.0.0 (7.0.21.63101), X64 RyuJIT DefaultJob : .NET 7.0.0 (7.0.21.63101), X64 RyuJIT

Method	Mean	Error	StdDev	Gen 0	Allocated
Solution0	7,494.9 ns	298.81 ns	866.91 ns	3.6850	11 KB

ladeak

Thank you for the longer answer on my question. I choose to come back here with a longer reply because it feels a more appropriate form. After reading your post I still feel using a StubClock with constant value is my 'default' choice. I write this reply so that myself also understand why that would be the case.

Context

• You likely have more experience working with DateTime
• Maybe I have been exposed to a different type of business processes using DateTime that implies different usage
• Maybe there is a pendulum swing waiting for me to happen

Determinism

ladeak

using System.Buffers;
using Microsoft.Extensions.ObjectPool;

public class ChainedPolicy : IPooledObjectPolicy<ChainedArrayBufferWriter<byte>>
{
    public ChainedArrayBufferWriter<byte> Create()
    {
        return new ChainedArrayBufferWriter<byte>();
    }