Evaluating String Pattern Matching in .NET: Performance, Readability, and Nuances

Usually, when we come across tips on string pattern matching online, they tend to focus on three basic approaches: using the StartsWith and EndsWith methods, using the indexer property with the ^ operator, and using list patterns.

In this article, we’ll take a slightly deeper look and answer a few practical questions: when to use each of these patterns, how they differ in terms of performance and usage scenarios, and whether there are other string-matching patterns worth considering.

We will use BenchmarkDotNet on .NET 10 for the benchmark tests. All benchmarks are run on a Windows 11 Pro machine with a 12th Gen Intel Core i7-1255U processor, 40 GB RAM, using an x64 environment.

Below are three common string pattern matching techniques. One might argue that StartsWith is the most readable simply because it's the most established and familiar. However, the new list pattern is arguably superior in terms of readability, as it appears shorter, cleaner, and more expressive.

Surprisingly, StartsWith is often evaluated based on its string overload. This is misleading, as that specific implementation carries a massive performance penalty and is roughly 1000 times slower than the optimized patterns discussed below.

Now, let us move to the benchmark tests for the following three patterns. We will also add a few more for comparison purposes.

if (email.StartsWith("a") && email.EndsWith("m"))
{
    Console.WriteLine("Starts with a, ends with m");
}

if (email[0] == 'a' && email[^1] == 'm')
{
    Console.WriteLine("Starts with a, ends with m");
}

if (email is ['a', .., 'm'])
{
    Console.WriteLine("Starts with a, ends with m");
}

First of all, we included the StartsWith overload with a char parameter to determine if it offers a performance advantage. Next, we introduced the method using StringComparison.Ordinal to serve as a baseline. Two Regex-based patterns were incorporated to demonstrate the significant overhead of the regex engine compared to specialized string methods. Finally, we implemented two Span<char> versions to evaluate whether direct memory access provides a substantial performance boost.

Beyond standard test values, we included several edge-case scenarios to provide a more comprehensive performance overview.

Now, let us examine the results obtained after running the tests. We shall observe how the different implementations compare in terms of execution time and memory allocation.

using System.Text.RegularExpressions;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Order;
using BenchmarkDotNet.Running;

BenchmarkRunner.Run<StringPerformanceBenchmark>();

[ShortRunJob]
[MemoryDiagnoser]
[RankColumn]
[Orderer(SummaryOrderPolicy.FastestToSlowest)]
[DisassemblyDiagnoser(printSource: true, maxDepth: 3)]
public partial class StringPerformanceBenchmark
{
    [Params("", "a@m", "admin@company.com", "LONG_EMAIL", "wrong_start_and_end")]
    public string EmailInput { get; set; }

    private string _email = string.Empty;
    private static readonly Regex EmailRegexGenerated = MyRegex();
    private static readonly Regex EmailRegexCompiled = new(@"^a.*m$", RegexOptions.Compiled);

    [GlobalSetup]
    public void Setup()
    {
        _email = EmailInput == "LONG_EMAIL"
            ? "a" + new string('n', 2000) + "m"
            : EmailInput;
    }

    [Benchmark]
    public bool UseMethods() =>
        _email.StartsWith("a") && _email.EndsWith("m");

    [Benchmark(Baseline = true)]
    public bool UseMethodsOrdinal() =>
        _email.StartsWith("a", StringComparison.Ordinal) &&
        _email.EndsWith("m", StringComparison.Ordinal);

    [Benchmark]
    public bool ViaCharMethods() =>
        _email.StartsWith('a') && _email.EndsWith('m');

    [Benchmark]
    public bool UseIndexer() =>
        _email.Length > 0 && _email[0] == 'a' && _email[^1] == 'm';

    [Benchmark]
    public bool UseListPattern() => _email is ['a', .., 'm'];

    [Benchmark]
    public bool ViaSpan()
    {
        ReadOnlySpan<char> span = _email.AsSpan();
        return span is ['a', .., 'm'];
    }

    [Benchmark]
    public bool ViaSpanDirect()
    {
        var span = _email.AsSpan();
        return span.Length > 0 && span[0] == 'a' && span[^1] == 'm';
    }
    
    [Benchmark]
    public bool ViaCompiledRegex() =>
        EmailRegexCompiled.IsMatch(_email);

    [Benchmark]
    public bool ViaGeneratedRegex() =>
        EmailRegexGenerated.IsMatch(_email);

    [GeneratedRegex(@"^a.*m$")]
    private static partial Regex MyRegex();
}

As expected, both Regex methods ranked last in performance, positioned just below the original StartsWith method. We shall examine the reasons for such poor performance later in this article. What was not anticipated, however, is that the Regex methods do not allocate additional memory.

The top performers are ViaCharMethods, UseIndexer, UseMethodsOrdinal, and UseListPattern. The Span<T> implementations did not demonstrate any significant advantages in these scenarios. This lack of performance gain makes them less appropriate, considering their lower-level nature and the associated maintenance overhead.

At the beginning of our testing, we intentionally included the DisassemblyDiagnoser attribute to analyze the generated assembly code. The output reveals that the fastest methods also generate the most concise instruction sets, ranging from 20 to 100 bytes per method. In contrast, the slower methods produce significantly larger instruction sets, often exceeding 1,000 bytes.

We can see that with realistic data (non-empty and of standard length), the performance gap disappears. The List Pattern is even more efficient because it is better optimized for medium-length strings than the manual checks in the indexer implementation. At the same time, it is significantly more readable than the version using StringComparison.Ordinal.

; StringPerformanceBenchmark.UseListPattern()
; Method signature: public bool UseListPattern() => _email is ['a', .., 'm'];

       ; 1. Load string reference and perform Null Check
       mov       rax,[rcx+10]               ; Load _email object reference into rax
       test      rax,rax                    ; Check if the reference is null
       je        short M00_L00              ; If null, jump to return false

       ; 2. Length Validation (Safety Check)
       mov       ecx,[rax+8]                ; Load string length (stored at offset +8) into ecx
       cmp       ecx,2                      ; Check if length is at least 2
       jl        short M00_L00              ; If length < 2, the pattern cannot match; return false

       ; 3. Check First Character ('a' = 0x61)
       cmp       word ptr [rax+0C],61       ; Compare character at offset +0C (first char) with 'a'
       jne       short M00_L00              ; If not equal, jump to return false

       ; 4. Check Last Character ('m' = 0x6D)
       dec       ecx                        ; Decrement length to get the index of the last character
       cmp       word ptr [rax+rcx*2+0C],6D ; Calculate address and compare last char with 'm'
       
       ; 5. Finalize Result
       sete      al                         ; Set al to 1 if equal, 0 otherwise
       movzx     eax,al                     ; Zero-extend result to eax
       ret                                  ; Return result

M00_L00:
       xor       eax,eax                    ; Standard "Return False" block
       ret                                  ; Return 0

To be continued...