Should avoid boxing of value types when using string interpolation in a StringBuilder

[friflo]

I came across of the boxing behavior of StringBuilder when writing a Logger which aims to prevent allocations using string interpolation for its API.
It does this by utilizing a [InterpolatedStringHandler] struct.

Small snippet to reproduce the boxing behavior of StringBuilder.

public static void Test_StringBuilder_string_interpolation()
{
    var sb = new StringBuilder(50);
    
    var start = GC.GetAllocatedBytesForCurrentThread();
    sb.Append($"float:{1.4f}");
    // boxing is caused by the cast to ISpanFormattable
    //  if (((ISpanFormattable)value).TryFormat(...)
    var diff = GC.GetAllocatedBytesForCurrentThread() - start;
    
    Assert.AreEqual(0, diff); // diff == 24
}

The line that boxes is at:

runtime/src/libraries/System.Private.CoreLib/src/System/Text/StringBuilder.cs

Line 2904 in 39a31f0

if (((ISpanFormattable)value).TryFormat(destination, out int charsWritten, default, _provider)) // constrained call avoiding boxing for value types

[friflo]

To avoid boxing the approach described below could be used.

The method called by string interpolation is: public void AppendFormatted<T>(T value)
in System.Text.StringBuilder.AppendInterpolatedStringHandler.

So the method uses an unconstraint generic type.
To avoid boxing a delegate could be created which calls TryFormat() with a constraint type:
where T : ISpanFormattable

So the call of TryFormat() would change to

SpanFormat<T>.TryFormat(value, destination, out int charsWritten, default, _provider);

Here the small snippet which creates the delegate.

internal delegate bool SpanFormattableTryFormat<in T>(T value, Span<char> destination, out int charsWritten, ReadOnlySpan<char> format, IFormatProvider? provider);

internal static class SpanFormat<T>
{
    internal static readonly SpanFormattableTryFormat<T> TryFormat = (SpanFormattableTryFormat<T>)SpanFormat.CreateTryFormat(typeof(T), typeof(SpanFormattableTryFormat<T>));
}

internal static class SpanFormat
{
    internal static Delegate CreateTryFormat(Type type, Type delegateType)
    {
        var methodInfo      = typeof(SpanFormat).GetMethod("TryFormat", BindingFlags.Static | BindingFlags.NonPublic)!;
        var genericMethod   = methodInfo.MakeGenericMethod(type);
        return Delegate.CreateDelegate(delegateType, genericMethod);
    }
    
    internal static bool TryFormat<TSpanFormattable> (TSpanFormattable value, Span<char> destination, out int charsWritten, ReadOnlySpan<char> format, IFormatProvider? provider)
        where TSpanFormattable : ISpanFormattable
    {
        return value.TryFormat(destination, out charsWritten, format, provider);
    }
}

[stephentoub]

The line that boxes is at:

That boxing doesn't happen in optimized tier 1 as it gets optimized out. If you're seeing allocation from that, you're likely looking at umoptimized and/or tier 0.

[friflo]

You are right. I verified this. Even if I trust your statements :)

I also saw the comment: // constrained call avoiding boxing for value type.
The number of iterations must be very high in this test case to get the JIT optimization triggered.

The inherent question using this approach. "When can it be expected the optimizer do its optimization".
I guess there is no definitive answer to this. At least a "high" number of repeated execution is required.

public static void Test_StringBuilder_string_interpolation()
{
    var sb = new StringBuilder(50);
    for (int i = 0; i < 10_000_000; i++) {
        Append(sb, 1.4f);
        sb.Clear();
    }
    var start = GC.GetAllocatedBytesForCurrentThread();
    Append(sb, 1.4f);
    var diff = GC.GetAllocatedBytesForCurrentThread() - start;
    
    Assert.AreEqual(0, diff); // diff == 0  after many repeated Append() calls triggering tier 1 optimization 
}

private static void Append(StringBuilder sb, float value) => sb.Append($"float:{value}");

[friflo]

For context. I do this type of allocation checks on many places in my unit tests.
So this kind of checks typically executes bigger parts of the codebase. Each executed part is expected to be allocation free.

Nice to have
It would be nice to instruct the JIT optimizer to apply the optimization at the first call for each specific type.
So all subsequent calls are using the optimized version.

By this checking for memory allocations would be 100% predictive / deterministic.
E.g. forcing instant optimization with a #pragma. But I guess this feature is not really possible.

[stephentoub]

The number of iterations must be very high in this test case to get the JIT optimization triggered.

Search the web for "tiered compilation". It's an on-by-default feature that only turns on optimizations for methods after they've been demonstrated to be used enough. It requires many fewer iterations than you're citing, but once it's decided to recompile the method, it can take some time (milliseconds) for that to happen, and in that period of time you can end up running such a tiny method a lot before it's patched.

E.g. forcing instant optimization with a #pragma. But I guess this feature is not really possible.

You can opt out of tiering in multiple ways, including process-wide via config switches, e.g.
https://learn.microsoft.com/en-us/dotnet/core/runtime-config/compilation#tiered-compilation
or on a method-by-method level using [MethodImpl(MethodImplOptions.AggressiveOptimization)]. Just keep in mind that bypassing tier 0 like that has real downsides, such as effectively disabling profile guided optimization.