.net, C# and programming

Collections search

Sergey Rogatnev — Thu, 09 Apr 2026 00:00:00 GMT

During interviews, we often hear — or say ourselves — that searching in an array is slower than in a hashtable. Some might even recall that array search has linear complexity, or O(n), while a hash table has constant complexity, O(1). But does this hold true in practice? What if there are situations where searching in an array turns out to be faster? Let's not rush to conclusions.

So, let's compare searching in an array and a HashSet on small collections, using different types: a primitive int and a reference type string.

Full benchmark code. Click to expand.

using System.Collections.Generic;
using System.Linq;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Jobs;

namespace Benchmarks
{
[ShortRunJob(RuntimeMoniker.Net60)]
[ShortRunJob(RuntimeMoniker.Net80)]
[ShortRunJob(RuntimeMoniker.Net10_0)]
[HideColumns("Job", "Error", "StdDev", "Gen0", "Median")]
[DisassemblyDiagnoser(printSource: true, maxDepth: 2)]
public class HashSetContainsBenchmark
{
[Params(1, 10, 100, 1000)]
public int Size { get; set; }

        private int[] _arrayInt;
        private HashSet<int> _hashSetInt;
        private int _missingInt;

        private string[] _arrayString;
        private HashSet<string> _hashSetString;
        private string _missingString;

        [GlobalSetup]
        public void Setup()
        {
            // --- Int Setup ---
            var intData = Enumerable.Range(0, Size).ToArray();
            _arrayInt = intData;
            _hashSetInt = new HashSet<int>(intData);
            _missingInt = Size + 1;

            // --- String Setup ---
            var stringData = Enumerable.Range(0, Size).Select(i => $"value-{i}").ToArray();
            _arrayString = stringData;
            _hashSetString = new HashSet<string>(stringData);
            _missingString = "value-a";
        }

        // --- Int Benchmarks ---
        [Benchmark(Description = "Array.Contains (Int)")]
        public bool Int_Array() => _arrayInt.Contains(_missingInt);

        [Benchmark(Description = "HashSet.Contains (Int)")]
        public bool Int_HashSet() => _hashSetInt.Contains(_missingInt);

        // --- String Benchmarks ---
        [Benchmark(Description = "Array.Contains (String)")]
        public bool String_Array() => _arrayString.Contains(_missingString);

        [Benchmark(Description = "HashSet.Contains (String)")]
        public bool String_HashSet() => _hashSetString.Contains(_missingString);
    }
}

| Method                      | Runtime   | Size |     Mean | Code Size |
|-----------------------------|-----------|------|---------:|----------:|
|  Array.Contains (Int)       | .NET 6.0  | 1    | 3.443 ns |      50 B |
|  HashSet.Contains (Int)     | .NET 6.0  | 1    | 2.052 ns |     447 B |
|  Array.Contains (String)    | .NET 6.0  | 1    | 8.621 ns |      57 B |
|  HashSet.Contains (String)  | .NET 6.0  | 1    | 4.741 ns |     737 B |
|  Array.Contains (Int)       | .NET 8.0  | 1    | 2.676 ns |      40 B |
|  HashSet.Contains (Int)     | .NET 8.0  | 1    | 1.954 ns |     385 B |
|  Array.Contains (String)    | .NET 8.0  | 1    | 9.639 ns |      51 B |
|  HashSet.Contains (String)  | .NET 8.0  | 1    | 4.599 ns |     351 B |
|  Array.Contains (Int)       | .NET 10.0 | 1    | 1.193 ns |     669 B |
|  HashSet.Contains (Int)     | .NET 10.0 | 1    | 1.666 ns |     377 B |
|  Array.Contains (String)    | .NET 10.0 | 1    | 2.285 ns |     548 B |
|  HashSet.Contains (String)  | .NET 10.0 | 1    | 3.698 ns |     233 B |

Intuitively, it seems that iterating over one element in an array should be faster than the more complex mechanism of hash-based searching. As we can see, even when searching in a collection of a single int, the array loses to HashSet up until .NET 10:

And even then, the advantage is quite small.

We observe the same picture for strings:

Notice how in .NET 10, array search for strings (2.285 ns) even beats HashSet (3.698 ns) — we'll explain why later.

Alright, collections of one element are weird. Let's take the larger size — 10 elements. Surely, the advantage of HashSet should become more obvious there:

| Method                      | Runtime   | Size |      Mean | Code Size |
|-----------------------------|-----------|------|----------:|----------:|
|  Array.Contains (Int)       | .NET 6.0  | 10   |  4.059 ns |      50 B |
|  HashSet.Contains (Int)     | .NET 6.0  | 10   |  2.901 ns |     447 B |
|  Array.Contains (String)    | .NET 6.0  | 10   | 33.465 ns |      57 B |
|  HashSet.Contains (String)  | .NET 6.0  | 10   |  5.807 ns |     737 B |
|  Array.Contains (Int)       | .NET 8.0  | 10   |  3.137 ns |      40 B |
|  HashSet.Contains (Int)     | .NET 8.0  | 10   |  2.497 ns |     397 B |
|  Array.Contains (String)    | .NET 8.0  | 10   | 31.164 ns |      51 B |
|  HashSet.Contains (String)  | .NET 8.0  | 10   |  5.937 ns |     377 B |
|  Array.Contains (Int)       | .NET 10.0 | 10   |  1.639 ns |     729 B |
|  HashSet.Contains (Int)     | .NET 10.0 | 10   |  2.230 ns |     377 B |
|  Array.Contains (String)    | .NET 10.0 | 10   | 18.063 ns |     548 B |
|  HashSet.Contains (String)  | .NET 10.0 | 10   |  4.583 ns |     233 B |

Do you see the oddities already? Here they are:

The search time in HashSet remains roughly the same regardless of the framework version, but array search keeps getting better and better. Moreover, in .NET 10, the array overtakes HashSet! How come? Does array search also work in constant time now? It seems we are on the verge of a grand discovery. Let's test our hypothesis on collections of 100 elements:

| Method                      | Runtime   | Size |       Mean | Code Size |
|-----------------------------|-----------|------|-----------:|----------:|
|  Array.Contains (Int)       | .NET 6.0  | 100  |  13.073 ns |      50 B |
|  HashSet.Contains (Int)     | .NET 6.0  | 100  |   2.116 ns |     447 B |
|  Array.Contains (String)    | .NET 6.0  | 100  | 168.924 ns |      57 B |
|  HashSet.Contains (String)  | .NET 6.0  | 100  |   8.306 ns |     737 B |
|  Array.Contains (Int)       | .NET 8.0  | 100  |   4.381 ns |      40 B |
|  HashSet.Contains (Int)     | .NET 8.0  | 100  |   1.857 ns |     385 B |
|  Array.Contains (String)    | .NET 8.0  | 100  |  93.214 ns |      51 B |
|  HashSet.Contains (String)  | .NET 8.0  | 100  |   7.938 ns |     377 B |
|  Array.Contains (Int)       | .NET 10.0 | 100  |   3.401 ns |     736 B |
|  HashSet.Contains (Int)     | .NET 10.0 | 100  |   1.774 ns |     377 B |
|  Array.Contains (String)    | .NET 10.0 | 100  |  71.121 ns |     562 B |
|  HashSet.Contains (String)  | .NET 10.0 | 100  |   6.806 ns |     233 B |

Unfortunately, a miracle didn't happen. Now the array consistently loses to HashSet in searching. But the difference for the int type is still not that significant:

Let's look at the growth of search time in an array relative to its size. For clarity, let's add an array of 1000 elements:

As we can see, only in .NET 6 do we begin to observe linear growth after 100 elements. And in versions 8 and 10, the growth, if not logarithmic, is heavily smoothed out.

It's time to dive deeper, specifically into exactly how array search is performed. Calling the Contains method on an array ultimately leads to calling the static Array.IndexOf method. But this is where the differences begin.

.NET 6

Using some loop-unrolling optimizations and fast access to array elements, .NET checks each element for equality:

...
while (length >= 8)
{
    length -= 8;

    if (value.Equals(Unsafe.Add(ref searchSpace, index)))
        goto Found;
    if (value.Equals(Unsafe.Add(ref searchSpace, index + 1)))
        goto Found1;
    if (value.Equals(Unsafe.Add(ref searchSpace, index + 2)))
        goto Found2;
    if (value.Equals(Unsafe.Add(ref searchSpace, index + 3)))
        goto Found3;
    if (value.Equals(Unsafe.Add(ref searchSpace, index + 4)))
        goto Found4;
    if (value.Equals(Unsafe.Add(ref searchSpace, index + 5)))
        goto Found5;
    if (value.Equals(Unsafe.Add(ref searchSpace, index + 6)))
        goto Found6;
    if (value.Equals(Unsafe.Add(ref searchSpace, index + 7)))
        goto Found7;

    index += 8;
}
// the remainder of the array (less than 8 elements) is checked next

As you can see, we sequentially check each element and get our honest O(N) complexity. Nothing unusual so far.

.NET 8

Starting with this version, the situation changes drastically. The SpanHelpers.NonPackedIndexOfValueType method comes into play, which, in addition to loop unrolling, contains a powerful hardware optimization—vectorization:

if (Vector512.IsHardwareAccelerated && length >= Vector512<TValue>.Count)
{
    Vector512<TValue> left = Vector512.Create<TValue>(value);
    //...
}
else if (Vector256.IsHardwareAccelerated && length >= Vector256<TValue>.Count)
{
    Vector256<TValue> left = Vector256.Create<TValue>(value);
    //...
}
else
{
    Vector128<TValue> left = Vector128.Create<TValue>(value);
    //...
}

We can see the use of new types: Vector128, Vector256, Vector512 — collections for working with vector data. And pay attention to the IsHardwareAccelerated property being checked in every condition — this is where the magic lies. It determines whether your processor supports working with vectors of 128, 256, and 512 bits in length, respectively.

Using the Vector512 class allows operating on 16 int array elements at once. 512 bits = 64 bytes, meaning the vector holds 16 values of type int at 4 bytes each.

Unfortunately, we now have to dive into assembler to better understand how this works:

cmp r8d,4
jl near ptr M01_L03          ; If elements < 4, process one by one
cmp r8d,10h                  ; 0x10 = 16 decimal
jl near ptr M01_L18          ; If elements < 16, switch to processing using a 256-bit register (ymm)
vpbroadcastd zmm0,edx        ; Load the target value edx into the 512-bit register zmm0. Now zmm0 looks like [edx, edx, edx, ..., edx]
...
vmovups zmm1,[rcx]           ; Load the first 16 elements from memory into the 512-bit register zmm1
vpcmpeqd k1,zmm1,zmm0        ; Compare zmm1 and zmm0 for equality
kortestw k1,k1               ; Check if there is at least one match
...

vpcmpeqd is an instruction that compares two vectors element-by-element and saves the result into a special register k1. If the fifth element matches, the fifth bit in k1 will be set to 1.
kortestw checks this bitmask. If it equals 0, it means the target number is not present in the first 16 elements.

At first glance, it looks complicated, but essentially, this is a continuation of the loop unrolling concept, just at the hardware level. And the new framework versions hide all the complexity of such optimizations from us. Ultimately, there is no magic, and array search is still O(N). Even if it is O(N/16).

This magic only works on modern processors that support AVX-512 instructions (or AVX2 for 256-bit). If you run this code on older hardware, .NET will gracefully fall back to Vector128 or a regular loop.

.NET 10

Let me remind you that in this version, the results for an array of length 10 got even better and even surpassed HashSet. At the same time, the search algorithm itself hasn't changed; the code is exactly the same. Registers larger than 512 bits haven't been invented yet. So, what's the deal? I assume that PGO (Profile-Guided Optimization) kicked in, and the compiler decided that searches will most often occur in medium-sized arrays (8–15 elements), rearranged the comparison blocks to avoid unnecessary jumps, and saved the processor a couple more clock cycles.

And remember how earlier we made a mental note of why string array search became so good in .NET 10? It's time to figure that out as well.

Let's look at the benchmark once again:

| Method                  | Runtime   | Size |     Mean | Code Size |
|-------------------------|-----------|------|---------:|----------:|
| Array.Contains (String) | .NET 8.0  | 1    | 9.639 ns |      51 B |
| Array.Contains (String) | .NET 10.0 | 1    | 2.285 ns |     548 B |

Besides the nearly fourfold difference in speed, we also see a multiple-fold difference in Code Size. For .NET 8, the compiler didn't think twice and redirected the Contains method call to the generic Array.IndexOf method, which calls the virtual bool Equals(object obj) method for each array element. It's reliable, but not fast.

However, in .NET 10, the compiler applied a new technique called "devirtualization" — more specifically, Guarded Devirtualization. It is understood that our collection is an array of strings and only strings. This means we can skip all those generic calls and bypass the virtual method table dispatch, and simply inline the entire string comparison loop. That is why we get 548 bytes of code versus 51. But! We get specific code for searching a string in an array, which works much faster. To see this, let's look at the assembly code again:

...
mov r8,offset MT_System.String
cmp [rcx],r8                ; Verify that we definitely have a string. Hence Guarded Devirtualization.
jne short M00_L08           ; Otherwise, compare via classic Equals
...
mov r8d,[rcx+8]             ; Read the length of the current string
cmp r8d,[rsi+8]             ; Compare it with the length of the target string
je short M00_L07            ; If lengths match - compare the strings themselves byte by byte
...
M00_L07:
lea rax,[rcx+0C]
...
lea rdx,[rsi+0C]            ; Get a pointer to the byte array where strings are stored
mov rcx,rax
call qword ptr [7FFD2A46C330] ; System.SpanHelpers.SequenceEqual - call the method that compares 2 byte arrays
...

At the same time, SequenceEqual also supports vector operations and hardware acceleration. Wow! That's powerful! I didn't even suspect what a tremendous amount of work goes on behind a simple string search in an array.

Conclusions

Once again, the obvious conclusion suggests itself: simply updating .NET will yield a performance boost (and therefore resource savings). Also, there is no magic; O(N) is still O(N), which is clearly noticeable at large values. However, for small values (5–10 elements), things might not be so straightforward.

But can we do better? To avoid O(N), even with hardware acceleration, but also without constantly paying the hashing overhead? We'll see...

Analyzer

I've added a rule to my analyzer that will suggest replacing an array (or list) with a HashSet if Contains is called on it. This is useful for .NET 8 and below, and remains relevant for .NET 10 with collections larger than ~15 elements. For finer tuning, you can adjust the trigger threshold in .editorconfig — for example, only starting from five elements:

dotnet_diagnostic.CI0008.min_items_count = 5

Collection initializer: List

Sergey Rogatnev — Thu, 27 Nov 2025 00:00:00 GMT

We're all used to write new List<int> { 1, 2, 3, 4 } or new int[] { 1, 2, 3, 4} to initialize collections with values. Syntactically, they look similar, but the behavior is different, and you should be careful if you are worried about performance.

Array

As we know, arrays contain a sequence of fixed-size elements. Once created, their size cannot be changed for the entire lifetime of the array.

var array = new int[] { 1, 2, 3, 4};

List<T>

When we don't know the final size of a collection, or we need to add/remove elements during its life cycle, using List<T> type is appropriate.

var list = new List<int>();
list.Add(1);
list.Add(2);

At first glance, it might seem like we can always use a list instead of an array — it has all the capabilities of an array, but it can also be dynamically resized. But to decide whether to use a list, we need to understand more about its internal structure.

Part of the source code:

public class List<T> : IList<T>, IList, IReadOnlyList<T>
{
    private const int DefaultCapacity = 4;

    internal T[] _items;
    internal int _size;

    private static readonly T[] s_emptyArray = new T[0];

    // Constructs a List. The list is initially empty and has a capacity
    // of zero. Upon adding the first element to the list the capacity is
    // increased to DefaultCapacity, and then increased in multiples of two
    // as required.
    public List()
    {
        _items = s_emptyArray;
    }
    ...

    public int Capacity
    {
        get => _items.Length;
        set {...}
    }

    public int Count => _size;
}

_items - internal array for storing elements;
_size - the number of elements in the array and the total size of the list;
Capacity - the size of the _items array and the maximum number of elements that can fit into it without resizing.

Resizing a list

In simple terms, we can say that a list is an array that can be resized as needed.

Every time we try to add another item, the list checks if there is enough free space in _items, otherwise it sets the new capacity:

internal void Grow(int capacity)
{
    ...
    int newCapacity = _items.Length == 0 ? DefaultCapacity : 2 * _items.Length;
    ...
    Capacity = newCapacity;
}

Let's take a closer look at the property Capacity:

// Gets and sets the capacity of this list.  The capacity is the size of
// the internal array used to hold items.  When set, the internal
// array of the list is reallocated to the given capacity.
public int Capacity
{
    get => _items.Length;
    set
    {
        if (value < _size)
        {
            ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_SmallCapacity);
        }

        if (value != _items.Length)
        {
            if (value > 0)
            {
                T[] newItems = new T[value];
                if (_size > 0)
                {
                    Array.Copy(_items, newItems, _size);
                }
                _items = newItems;
            }
            else
            {
                _items = s_emptyArray;
            }
        }
    }
}

So, what do we see? Initially, each list is created with an empty internal array. After the first element is added, the list creates a new array with 4 elements (DefaultCapacity is 4). And when the current array is exhausted, a new one is created with double the size, and all elements are copied.

Performance

What happens when we create a new list and initialize it with values?

var list = new List<int> { 1, 2, 3, 4, 5 };

This looks like array initialization, but it works completely differently. According to the documentation, any type that implements IEnumerable and has an Add method can be used with a collection initializer.

So, the previous example is just a shorthand form of successive calls to the Add method:

var list = new List<int>();
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(4);
list.Add(5);

The compiler simply transforms the short collection initializer and automatically adds the necessary calls. This can result in a performance penalty.

Let's take a closer look at the process of adding 5 elements:

Before the first call to Add the list is empty, the internal array is empty.
The first element added creates a new internal array with 4 elements.
Elements 2, 3, 4 do not change anything when added.
When we add the fifth element, the internal array is full and needs to be resized. A new array of size 8 is created, all elements are copied from the previous array, and the fifth element is added.

So, we end up with a list with 5 elements and an internal array with 8 elements. We've created two arrays, and the final one is wasting 37.5% of its space. As you might have guessed, creating new arrays and copying elements results in memory allocation and takes additional time.

This could be an unpleasant surprise in critical areas. Do we have a solution? Yes!

Capacity

If we know or guess the finite size of the list, we can create it with an initial capacity (Capacity).

var list = new List<int>(5);
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(4);
list.Add(5);

var list = new List<int>(5) { 1, 2, 3, 4, 5 };

Now we immediately create one internal array of 5 elements, and there are no more unnecessary memory allocations.

Benchmark

Let's compare creating lists with and without initial capacity.

Full benchmark code. Click to expand.

using System.Collections.Generic;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Jobs;

namespace ListBenchmark
{
    [ShortRunJob(RuntimeMoniker.Net48)]
    [ShortRunJob(RuntimeMoniker.NetCoreApp31)]
    [ShortRunJob(RuntimeMoniker.Net80)]
    [ShortRunJob(RuntimeMoniker.Net10_0)]
    [MemoryDiagnoser]
    [HideColumns("Job", "Error", "StdDev", "Gen0")]
    public class InitListBenchmark
    {
        [BenchmarkCategory("One")]
        [Benchmark]
        public List<int> InitList1()
        {
            return new List<int> {1};
        }

        [BenchmarkCategory("One")]
        [Benchmark]
        public List<int> InitListWithSize1()
        {
            return new List<int>(1) {1};
        }

        [BenchmarkCategory("Five")]
        [Benchmark]
        public List<int> InitList5()
        {
            return new List<int> {1, 2, 3, 4, 5};
        }
        
        [BenchmarkCategory("Five")]
        [Benchmark]
        public List<int> InitListWithSize5()
        {
            return new List<int>(5) {1, 2, 3, 4, 5};
        }
        
        [BenchmarkCategory("Ten")]
        [Benchmark]
        public List<int> InitList10()
        {
            return new List<int> {1, 2, 3, 4, 5, 6, 7, 8, 9, 0};
        }
        
        [BenchmarkCategory("Ten")]
        [Benchmark]
        public List<int> InitListWithSize10()
        {
            return new List<int>(10) {1, 2, 3, 4, 5, 6, 7, 8, 9, 0};
        }
    }
}

BenchmarkDotNet v0.15.6, Windows 10 (10.0.19045.6456/22H2/2022Update)
AMD Ryzen 7 7840H with Radeon 780M Graphics 3.80GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 10.0.100
[Host]                      : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v4
ShortRun-.NET 10.0          : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v4
ShortRun-.NET 8.0           : .NET 8.0.22 (8.0.22, 8.0.2225.52707), X64 RyuJIT x86-64-v4
ShortRun-.NET Core 3.1      : .NET Core 3.1.32 (3.1.32, 4.700.22.55902), X64 RyuJIT VectorSize=256
ShortRun-.NET Framework 4.8 : .NET Framework 4.8.1 (4.8.9310.0), X64 RyuJIT VectorSize=256

IterationCount=3 LaunchCount=1 WarmupCount=3

| Method             | Runtime            |      Mean | Allocated |
|--------------------|--------------------|----------:|----------:|
| InitList1          | .NET Framework 4.8 | 13.904 ns |      80 B |
| InitListWithSize1  | .NET Framework 4.8 |  6.658 ns |      72 B |
| InitList1          | .NET Core 3.1      | 11.091 ns |      72 B |
| InitListWithSize1  | .NET Core 3.1      |  7.407 ns |      64 B |
| InitList1          | .NET 8.0           | 10.084 ns |      72 B |
| InitListWithSize1  | .NET 8.0           |  6.838 ns |      64 B |
| InitList1          | .NET 10.0          |  8.170 ns |      72 B |
| InitListWithSize1  | .NET 10.0          |  6.638 ns |      64 B |
| InitList5          | .NET Framework 4.8 | 31.298 ns |     136 B |
| InitListWithSize5  | .NET Framework 4.8 | 12.013 ns |      88 B |
| InitList5          | .NET Core 3.1      | 26.466 ns |     128 B |
| InitListWithSize5  | .NET Core 3.1      |  9.446 ns |      80 B |
| InitList5          | .NET 8.0           | 23.714 ns |     128 B |
| InitListWithSize5  | .NET 8.0           | 15.587 ns |      80 B |
| InitList5          | .NET 10.0          | 20.002 ns |     128 B |
| InitListWithSize5  | .NET 10.0          |  8.712 ns |      80 B |
| InitList10         | .NET Framework 4.8 | 53.488 ns |     225 B |
| InitListWithSize10 | .NET Framework 4.8 | 18.185 ns |     104 B |
| InitList10         | .NET Core 3.1      | 44.371 ns |     216 B |
| InitListWithSize10 | .NET Core 3.1      | 12.496 ns |      96 B |
| InitList10         | .NET 8.0           | 38.707 ns |     216 B |
| InitListWithSize10 | .NET 8.0           | 12.024 ns |      96 B |
| InitList10         | .NET 10.0          | 33.854 ns |     216 B |
| InitListWithSize10 | .NET 10.0          | 15.822 ns |      96 B |

Setting the initial capacity prevents unnecessary memory allocations and results in better performance. And there's no excess memory traffic. The more elements we add to the list, the greater the difference we see in the benchmarks.

Analyzer

If performance is critical for your project, you should pay attention to these situations. Automatic diagnostics can help. I maintain a set of diagnostic tools based on Roslyn – Collections.Analyzer, and now it can detect lists with a collection initializer and without an initial capacity.

It's important to understand that the analyzer only sets the initial collection size to avoid unnecessary allocations during the initial collection phase. He cannot predict how the size of the collection will change in the future.

Recommendations

If you need a static collection that you won't modify (add or remove elements), use arrays.
If you are creating a list and exactly know its future size, set the initial capacity to that size.
If you are creating a list and don't know its future size, set the expected size.

Удаляем пробелы из строки

Сергей Рогатнев — Thu, 20 Nov 2025 00:00:00 GMT

Еще одна популярная задача при работе со строками — удалить из них пробельные символы. Можно представить, что нам нужно очистить пользовательский ввод (удалить пробелы вначале и конце строк в имени) или минифицировать json-объект. .NET предоставляет нам несколько возможностей для решения этой задачи, давайте рассмотрим самые популярные и попробуем найти наиболее эффективные. Заодно проверим, какие изменения произошли в новой версии .NET 10.

Для нашего примера будем считать пробельными символами сам пробел ( ), табуляцию (\t) и перевод строки (\n). На самом деле их больше, но для нашей задачи ограничимся только этими как самыми популярными.

Для бенчмарка я буду использовать самые новые и одни из самых старых версий фреймворка. Вряд ли для новых проектов выберут .NET Framework 4.8 для старта нового проекта, но интересно увидеть, как развивалась платформа во времени и что можно получить с переходом на новые версии.

Replace

Начнем с самого простого метода — Replace. Он может заменить нам все вхождения какого-то символа или подстроки на другой символ или подстроку. Для наших целей мы можем заменить пробельные символы на пустую строку (string.Empty). Но есть большой недостаток - этот метод не может заменить все пробельные символы сразу, поэтому мы вынуждены вызывать его для каждого пробельного символа:

private static string Replace(string s)
{
    return s.Replace(" ", string.Empty).Replace("\t", string.Empty).Replace("\n", string.Empty);
}

Посмотрим, как этот метод ведет себя в разных версиях .NET.

Полный код бенчмарка и все результаты вы найдете в конце статьи.

| Method           | Runtime            |        Mean |      Median | Allocated |
|------------------|--------------------|------------:|------------:|----------:|
| Replace          | .NET Framework 4.8 | 230.9093 ns | 227.7122 ns |     233 B |
| Replace          | .NET Core 3.1      | 158.6589 ns | 158.1439 ns |     216 B |
| Replace          | .NET 8.0           | 178.9700 ns | 177.7641 ns |     216 B |
| Replace          | .NET 10.0          | 157.4850 ns | 156.3763 ns |     216 B |

Если посмотреть на размер итоговой строки, то мы тратим примерно в 3 раза больше памяти. Очевидно, из-за того, что мы 3 раза вызываем метод Replace(), который создаёт новую строку. Из неё мы опять удаляем символы, что опять создаёт новую строку. И мы видим незначительное улучшение с каждой новой версией .NET.

И если в версии .NET 4.8 реализация метода Replace() находится внутри Common Language Runtime (CLR):

[SecuritySafeCritical]
[MethodImpl(MethodImplOptions.InternalCall)]
private extern string ReplaceInternal(string oldValue, string newValue);

То уже начиная с .NET Core 3.1 используется собственная реализация на указателях, а позже — с использованием типа Span и векторных инструкций.

К недостатку этого метода можно отнести то, что нужно явно перечислить все пробельные символы. А их, на самом деле, не так мало. Каждый новый символ - это лишний вызов метода Replace.

Наверняка, должны быть более оптимальные решения.

Regex

Регулярные выражения — универсальный способ решения для многих задач. И здесь он тоже применим. Как я говорил в предыдущем методе, мы не можем с помощью метода Replace() заменить все пробельные символы. А вот с помощью регулярных выражений можем:

private static readonly Regex EmptySpacesCompiled = new Regex(@"\s+", RegexOptions.Compiled);

private static string RegexCompiled(string s)
{
    return EmptySpacesCompiled.Replace(s, string.Empty);
}

private static readonly Regex EmptySpacesGenerated = GenerateRegex();

[GeneratedRegex(@"\s+")]
private static partial Regex GenerateRegex();

private static string RegexGenerated(string s)
{
    return EmptySpacesGenerated.Replace(s, string.Empty);
}

\s - специальное выражение, которое объединяет широкий набор пробельных символов, в том числе \t, \n, . Поэтому расширим задачу и дальше переходим к более общему варианту, где под пробельными понимаются все символы, которые char.IsWhiteSpace или \s считают пробельными. Таким образом, мы не пропустим ничего, как в случае с методом Replace.

Мы уже знаем по предыдущей статье, опция Compiled положительно сказывается на производительности, будем указывать её. Заодно проверим, как работает GeneratedRegex в этом случае.

| Method         | Runtime            |        Mean |      Median | Allocated |
|----------------|--------------------|------------:|------------:|----------:|
| RegexCompiled  | .NET Framework 4.8 | 872.0395 ns | 856.0633 ns |    1115 B |
| RegexGenerated | .NET Framework 4.8 |         N/A |         N/A |       N/A |
| RegexCompiled  | .NET Core 3.1      | 709.4504 ns | 696.5562 ns |     896 B |
| RegexGenerated | .NET Core 3.1      |         N/A |         N/A |       N/A |
| RegexCompiled  | .NET 8.0           | 202.2732 ns | 202.0966 ns |      64 B |
| RegexGenerated | .NET 8.0           | 191.2238 ns | 188.5849 ns |      64 B |
| RegexCompiled  | .NET 10.0          | 183.2023 ns | 181.1374 ns |      64 B |
| RegexGenerated | .NET 10.0          | 138.8752 ns | 138.8915 ns |      64 B |

Если в старых версиях фреймворка это решение не выдерживает сравнения даже с примитивным Replace(), то в 8-й и 10-й версии мы видим значительное улучшение.

А самое интересное — обратите внимание на потребление памяти. Всего 64 байта — итоговая строка. Это минимум, который можно получить в данном случае. Дело в том, что в новых версиях .NET Regex собирает итоговую строку из "кусочков" исходной без использования промежуточных состояний. За счет этого удаётся избежать дополнительной аллокации.

Удивительно, насколько оптимизированными стали регулярные выражения - мы видим кратный рост производительности и уменьшение использования памяти.

Но попробуем поискать более быстрый способ очистки строк.

Split + Concat

Еще один из способов удалить все пробелы — выделить из строки только непрерывные последовательности не пробельных символов, а потом собрать их в новую строку.

Это можно сделать с помощью метода Split:

private static string SplitConcat(string s)
{
    var parts = s.Split((char[])null, StringSplitOptions.RemoveEmptyEntries);
    return string.Concat(parts);
}

Передавая null в качестве первого параметра мы как раз хотим разделить нашу исходную строку по пробельным символам с использованием метода char.IsWhiteSpace. Этот метод работает с более широким набором пробельных символов, чем те, что мы описывали вначале. И указываем опцию RemoveEmptyEntries чтобы в результирующем массиве parts не оказалось пустых строк.

Проведем бенчмарк и сравним с предыдущими результатами. Для наглядности оставим только последние версии фреймворка.

| Method         | Runtime            |        Mean |      Median | Allocated |
|----------------|--------------------|------------:|------------:|----------:|
| Replace        | .NET 8.0           | 178.9700 ns | 177.7641 ns |     216 B |
| RegexCompiled  | .NET 8.0           | 202.2732 ns | 202.0966 ns |      64 B |
| RegexGenerated | .NET 8.0           | 191.2238 ns | 188.5849 ns |      64 B |
| SplitConcat    | .NET 8.0           |  97.6117 ns |  97.6992 ns |     376 B |
| Replace        | .NET 10.0          | 157.4850 ns | 156.3763 ns |     216 B |
| RegexCompiled  | .NET 10.0          | 183.2023 ns | 181.1374 ns |      64 B |
| RegexGenerated | .NET 10.0          | 138.8752 ns | 138.8915 ns |      64 B |
| SplitConcat    | .NET 10.0          |  90.2844 ns |  90.6640 ns |     376 B |

На данный момент этот способ является самым производительным во всех фреймворках. Но, к сожалению, он потребляет неприлично много памяти. Даже больше, чем трехкратный вызов метода Replace(). И большая часть этих затрат приходится на вызов метода Split(). Как мы уже знаем, результирующая строка занимает всего 64 байта, а значит 312 байт мы тратим на массив parts. Это большой симптом того, что мы выбрали некорректный способ для реализации задачи. Ведь действительно, сам по себе массив parts нам не нужен. Это только промежуточный результат, который мы потом должны объединить в строку, а сам массив отбросить.

LINQ

Мы можем ускориться и по возможности не создавать лишних объектов. Еще один популярный вариант:

private static string Linq(string s)
{
    return new string(s.Where(c => !char.IsWhiteSpace(c)).ToArray());
}

Берем из нашей исходной строки только не пробельные символы и создаём из них новую строку.

| Method           | Runtime            |        Mean |      Median | Allocated |
|------------------|--------------------|------------:|------------:|----------:|
| Linq             | .NET Framework 4.8 | 455.1868 ns | 457.0586 ns |     449 B |
| Linq             | .NET Core 3.1      | 331.2851 ns | 331.8324 ns |     448 B |
| Linq             | .NET 8.0           | 166.4657 ns | 165.9890 ns |     448 B |
| Linq             | .NET 10.0          |  70.9343 ns |  71.1085 ns |     192 B |

В общей сводной таблице он есть, но в рекомендациях не рассматривается из‑за аллокаций. На это влияет необходимость создания какого-то промежуточного массива для символов без пробелов.

Array buffer

Если нам всё равно нужно создавать какой-то массив, сделаем это сами заранее. Подготовим массив символов длинной исходной строки, заполним его символами без пробелов и создадим из него новую строку:

private static string Buffer(string s)
{
    var buffer = new char[s.Length];
    var index = 0;

    foreach (var c in s)
    {
        if (!char.IsWhiteSpace(c))
        {
            buffer[index++] = c;
        }
    }

    return new string(buffer, 0, index);
}

И посмотрим на результаты:

| Method           | Runtime            |        Mean |      Median | Allocated |
|------------------|--------------------|------------:|------------:|----------:|
| Buffer           | .NET Framework 4.8 |  72.8121 ns |  73.0219 ns |     168 B |
| Buffer           | .NET Core 3.1      |  56.3518 ns |  55.7937 ns |     160 B |
| Buffer           | .NET 8.0           |  38.5226 ns |  38.5226 ns |     160 B |
| Buffer           | .NET 10.0          |  31.0592 ns |  31.1676 ns |     160 B |

Выглядит впечатляюще - лучший метод по производительности на данный момент:

А главное, мы видим стабильное потребление памяти: только затраты на буфер и новую строку.

Но есть еще один трюк, который нам поможет улучшить результаты.

Stackalloc array buffer

Как мы знаем, такие типы данных как массивы, хранятся в управляемой куче (как раз эти данные попадают в метрику Allocated в бенчмарках). И доступ к этим данным несколько медленнее, чем к тем, что хранятся на стеке.

Обычно мы не управляем тем, где будут размещаться данные, но в .NET есть специальное выражение stackalloc, с помощью него можно выделить блок памяти прямо на стеке:

private static unsafe string StackallocBuffer(string s)
{
    var buffer = stackalloc char[s.Length];
    var index = 0;

    foreach (var c in s)
    {
        if (!char.IsWhiteSpace(c))
        {
            buffer[index++] = c;
        }
    }

    return new string(buffer, 0, index);
}

И запустим бенчмарк:

| Method           | Runtime            |        Mean |      Median | Allocated |
|------------------|--------------------|------------:|------------:|----------:|
| StackallocBuffer | .NET Framework 4.8 |  72.5095 ns |  70.6909 ns |      72 B |
| StackallocBuffer | .NET Core 3.1      |  50.3178 ns |  49.4475 ns |      64 B |
| StackallocBuffer | .NET 8.0           |  32.9556 ns |  32.7873 ns |      64 B |
| StackallocBuffer | .NET 10.0          |  26.7175 ns |  26.4192 ns |      64 B |

Теперь наш временный массив buffer создаётся не в общей куче, от чего получается еще небольшая прибавка в производительности и минимальное потребление памяти.

Но нужно учитывать, что размер стека ограничен и очень большие массивы создать не получится - получим StackOverflowException. Размер стека по-умолчанию равен 1 МБ и нужно учитывать это ограничение. Для коротких строк (десятки-сотни символов) это безопасно, для потенциально больших строк лучше оставить вариант с кучей.

Заключение

Как обычно мы рассмотрели самые популярные способы очистки строк от пробельных символов. Все они дают одинаковый результат, но используют разные механизмы. Если эта операция является частотной в вашем сценарии, то посмотрите, насколько оптимальный вариант вы используете. Виден значительный прогресс в каждой версии .NET и, в отличие от проверки строки на числа, здесь нет каких-то подводных камней.

Еще в общем бенчмарке есть вариант с использованием StringBuilder, но фактически он очень похож на решение с Buffer - также проходит строку один раз и накапливает символы без пробелов во внутренний буфер, поэтому подробно я про него не пишу, но можно посмотреть на результаты в таблице.

Рекомендации:

Если для вас важна простота решения и его читабельность, то подходят разные варианты Regex и метод Replace.
Для "горячих" мест используйте Buffer или StackallocBuffer в зависимости от ограничений на длину строки. Обычно это какие-то парсеры, логирование, нормализация входящих запросов и т.п.
Для старых версий фреймворка избегайте использования регулярных выражений для простых шаблонов - это будет не эффективно.

Полный код бенчмарка. Нажмите, чтобы развернуть.

using System;
using System.Linq;
using System.Text;
using System.Text.RegularExpressions;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Jobs;

namespace WhitespacesBenchmark
{
[MemoryDiagnoser]
[SimpleJob(RuntimeMoniker.Net10_0)]
[SimpleJob(RuntimeMoniker.Net80)]
[SimpleJob(RuntimeMoniker.NetCoreApp31)]
[SimpleJob(RuntimeMoniker.Net48)]
[HideColumns("Job", "Error", "StdDev", "Gen0")]
public partial class RemoveWhitespacesBenchmark
{
        private const string Value = " \tString  \t with \n\n\t\t whitespaces \t";

        [Benchmark]
        public string Replace()
        {
            return Replace(Value);
        }

        private static string Replace(string s)
        {
            return s.Replace(" ", string.Empty).Replace("\t", string.Empty).Replace("\n", string.Empty);
        }

        [Benchmark]
        public string SplitConcat()
        {
            return SplitConcat(Value);
        }

        private static string SplitConcat(string s)
        {
            var parts = s.Split((char[])null, StringSplitOptions.RemoveEmptyEntries);
            return string.Concat(parts);
        }

        [Benchmark]
        public string Linq()
        {
            return Linq(Value);
        }

        private static string Linq(string s)
        {
            return new string(s.Where(c => !char.IsWhiteSpace(c)).ToArray());
        }

        private static readonly Regex EmptySpacesCompiled = new Regex(@"\s+", RegexOptions.Compiled);

#if NET7_0_OR_GREATER
        private static readonly Regex EmptySpacesGenerated = GenerateRegex();

        [GeneratedRegex(@"\s+")]
        private static partial Regex GenerateRegex();
#endif

        [Benchmark]
        public string RegexCompiled()
        {
            return RegexCompiled(Value);
        }

        private static string RegexCompiled(string s)
        {
            return EmptySpacesCompiled.Replace(s, string.Empty);
        }

        [Benchmark]
        public string RegexGenerated()
        {
            return RegexGenerated(Value);
        }

        private static string RegexGenerated(string s)
        {
#if NET7_0_OR_GREATER
            return EmptySpacesGenerated.Replace(s, string.Empty);
#else
            return s;
#endif
        }

        [Benchmark]
        public string StringBuilder()
        {
            return StringBuilder(Value);
        }

        private static string StringBuilder(string s)
        {
            var sb = new StringBuilder(s.Length);

            foreach (var c in s)
            {
                if (!char.IsWhiteSpace(c))
                {
                    sb.Append(c);
                }
            }

            return sb.ToString();
        }

        [Benchmark]
        public string Buffer()
        {
            return Buffer(Value);
        }

        private static string Buffer(string s)
        {
            var buffer = new char[s.Length];
            var index = 0;

            foreach (var c in s)
            {
                if (!char.IsWhiteSpace(c))
                {
                    buffer[index++] = c;
                }
            }

            return new string(buffer, 0, index);
        }

        [Benchmark]
        public string StackallocBuffer()
        {
            return StackallocBuffer(Value);
        }

        private static unsafe string StackallocBuffer(string s)
        {
            var buffer = stackalloc char[s.Length];
            var index = 0;

            foreach (var c in s)
            {
                if (!char.IsWhiteSpace(c))
                {
                    buffer[index++] = c;
                }
            }

            return new string(buffer, 0, index);
        }
    }
}

Все результаты бенчмарков. Нажмите, чтобы развернуть.

BenchmarkDotNet v0.15.6, Windows 10 (10.0.19045.6456/22H2/2022Update)
AMD Ryzen 7 7840H with Radeon 780M Graphics 3.80GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 10.0.100
[Host]             : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v4
.NET 10.0          : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v4
.NET 8.0           : .NET 8.0.22 (8.0.22, 8.0.2225.52707), X64 RyuJIT x86-64-v4
.NET Core 3.1      : .NET Core 3.1.32 (3.1.32, 4.700.22.55902), X64 RyuJIT VectorSize=256
.NET Framework 4.8 : .NET Framework 4.8.1 (4.8.9310.0), X64 RyuJIT VectorSize=256


| Method           | Runtime            |        Mean |      Median | Allocated |
|------------------|--------------------|------------:|------------:|----------:|
| Replace          | .NET Framework 4.8 | 230.9093 ns | 227.7122 ns |     233 B |
| SplitConcat      | .NET Framework 4.8 | 164.1033 ns | 161.6289 ns |     610 B |
| Linq             | .NET Framework 4.8 | 455.1868 ns | 457.0586 ns |     449 B |
| RegexCompiled    | .NET Framework 4.8 | 872.0395 ns | 856.0633 ns |    1115 B |
| RegexGenerated   | .NET Framework 4.8 |         N/A |         N/A |       N/A |
| StringBuilder    | .NET Framework 4.8 | 115.0854 ns | 115.5498 ns |     217 B |
| Buffer           | .NET Framework 4.8 |  72.8121 ns |  73.0219 ns |     168 B |
| StackallocBuffer | .NET Framework 4.8 |  72.5095 ns |  70.6909 ns |      72 B |
| Replace          | .NET Core 3.1      | 158.6589 ns | 158.1439 ns |     216 B |
| SplitConcat      | .NET Core 3.1      | 122.7668 ns | 120.7053 ns |     376 B |
| Linq             | .NET Core 3.1      | 331.2851 ns | 331.8324 ns |     448 B |
| RegexCompiled    | .NET Core 3.1      | 709.4504 ns | 696.5562 ns |     896 B |
| RegexGenerated   | .NET Core 3.1      |         N/A |         N/A |       N/A |
| StringBuilder    | .NET Core 3.1      |  88.3582 ns |  88.6698 ns |     208 B |
| Buffer           | .NET Core 3.1      |  56.3518 ns |  55.7937 ns |     160 B |
| StackallocBuffer | .NET Core 3.1      |  50.3178 ns |  49.4475 ns |      64 B |
| Replace          | .NET 8.0           | 178.9700 ns | 177.7641 ns |     216 B |
| SplitConcat      | .NET 8.0           |  97.6117 ns |  97.6992 ns |     376 B |
| Linq             | .NET 8.0           | 166.4657 ns | 165.9890 ns |     448 B |
| RegexCompiled    | .NET 8.0           | 202.2732 ns | 202.0966 ns |      64 B |
| RegexGenerated   | .NET 8.0           | 191.2238 ns | 188.5849 ns |      64 B |
| StringBuilder    | .NET 8.0           |  50.1718 ns |  50.4215 ns |     208 B |
| Buffer           | .NET 8.0           |  38.5226 ns |  38.5226 ns |     160 B |
| StackallocBuffer | .NET 8.0           |  32.9556 ns |  32.7873 ns |      64 B |
| Replace          | .NET 10.0          | 157.4850 ns | 156.3763 ns |     216 B |
| SplitConcat      | .NET 10.0          |  90.2844 ns |  90.6640 ns |     376 B |
| Linq             | .NET 10.0          |  70.9343 ns |  71.1085 ns |     192 B |
| RegexCompiled    | .NET 10.0          | 183.2023 ns | 181.1374 ns |      64 B |
| RegexGenerated   | .NET 10.0          | 138.8752 ns | 138.8915 ns |      64 B |
| StringBuilder    | .NET 10.0          |  37.4249 ns |  37.6158 ns |     208 B |
| Buffer           | .NET 10.0          |  31.0592 ns |  31.1676 ns |     160 B |
| StackallocBuffer | .NET 10.0          |  26.7175 ns |  26.4192 ns |      64 B |

Отметка N/A ставится для методов, которые не существуют в данной версии фреймворка.

Инициализатор коллекций: List

Сергей Рогатнев — Sat, 27 Sep 2025 00:00:00 GMT

Мы все привыкли писать new List<int> { 1, 2, 3, 4 } или new int[] { 1, 2, 3, 4}, чтобы инициализировать коллекции какими-то значениями. Синтаксически это выглядит похоже, но поведение отличается, и вам следует быть осторожными, если вы заботитесь о производительности.

Массив

Как мы знаем, массивы содержат последовательность элементов фиксированного размера. После создания размер нельзя изменить в течение всего времени жизни массива.

var array = new int[] { 1, 2, 3, 4};

List<T>

Когда мы не знаем конечный размер коллекции или нам нужно добавлять/удалять элементы в течение ее жизненного цикла, подходит использование тип List<T>.

var list = new List<int>();
list.Add(1);
list.Add(2);

На первый взгляд может показаться, что мы всегда можем использовать список вместо массива — у него есть все возможности массива, но его также можно динамически изменять. Но чтобы решить, использовать ли список, нам нужно больше узнать о его внутренней структуре.

Часть исходного кода:

public class List<T> : IList<T>, IList, IReadOnlyList<T>
{
    private const int DefaultCapacity = 4;

    internal T[] _items;
    internal int _size;

    private static readonly T[] s_emptyArray = new T[0];

    // Constructs a List. The list is initially empty and has a capacity
    // of zero. Upon adding the first element to the list the capacity is
    // increased to DefaultCapacity, and then increased in multiples of two
    // as required.
    public List()
    {
        _items = s_emptyArray;
    }
    ...

    public int Capacity
    {
        get => _items.Length;
        set {...}
    }

    public int Count => _size;
}

_items - внутренний массив для хранения элементов;
_size - количество элементов в массиве и общий размер списка;
Capacity - размер массива _items и максимальное количество элементов, которые могут в него поместиться без изменения размера.

Изменение размера списка

Проще говоря, можно сказать, что список — это массив, который может изменять размер при необходимости.

Каждый раз, когда мы пытаемся добавить еще один элемент, список проверяет, достаточно ли в _items свободного места, в противном случае он устанавливает новую емкость:

internal void Grow(int capacity)
{
    ...
    int newCapacity = _items.Length == 0 ? DefaultCapacity : 2 * _items.Length;
    ...
    Capacity = newCapacity;
}

Давайте посмотрим поближе на свойство Capacity:

// Gets and sets the capacity of this list.  The capacity is the size of
// the internal array used to hold items.  When set, the internal
// array of the list is reallocated to the given capacity.
public int Capacity
{
    get => _items.Length;
    set
    {
        if (value < _size)
        {
            ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_SmallCapacity);
        }

        if (value != _items.Length)
        {
            if (value > 0)
            {
                T[] newItems = new T[value];
                if (_size > 0)
                {
                    Array.Copy(_items, newItems, _size);
                }
                _items = newItems;
            }
            else
            {
                _items = s_emptyArray;
            }
        }
    }
}

Итак, что мы видим? Изначально каждый список создается с пустым внутренним массивом. После добавления первого элемента список создает новый массив на 4 элемента (DefaultCapacity равно 4). И когда текущий массив исчерпан, создается новый с удвоенным размером, и все элементы копируются.

Производительность

Что происходит, когда мы создаем новый список и инициализируем его значениями?

var list = new List<int> { 1, 2, 3, 4, 5 };

Это выглядит как инициализация массива, но работает совершенно по-другому. Согласно документации, любой тип, который реализует IEnumerable и имеет метод Add может использоваться с инициализатором коллекции.

Таким образом, предыдущий пример — это просто краткая форма последовательных вызовов метода Add:

var list = new List<int>();
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(4);
list.Add(5);

Компилятор просто преобразует короткий инициализатор коллекции и автоматически добавляет необходимые вызовы. И это может вызвать снижение производительности.

Давайте подробнее рассмотрим процесс добавления 5 элементов:

Перед первым вызовом Add список пуст, внутренний массив пуст.
Первый добавленный элемент создает новый внутренний массив на 4 элемента.
Элементы 2, 3, 4 при добавлении ничего не меняют.
Когда мы добавляем пятый элемент, внутренний массив заполнен и требует изменения размера. Создается новый массив размером 8, все элементы копируются из предыдущего массива, и добавляется пятый элемент.

В итоге у нас есть список с 5 элементами и внутренний массив на 8 элементов. При этом мы создали 2 массива, и конечный тратит 37.5% своего пространства впустую. Как вы могли догадаться, создание новых массивов и копирование элементов приводит к выделению памяти и занимает дополнительное время.

Это может стать неприятным сюрпризом в критически важных местах. Есть ли у нас решение? Да!

Capacity

Если мы знаем или предполагаем конечный размер списка, мы можем создать его с начальной емкостью (Capacity).

var list = new List<int>(5);
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(4);
list.Add(5);

Или

var list = new List<int>(5) { 1, 2, 3, 4, 5 };

Теперь мы сразу создаем один внутренний массив на 5 элементов и больше нет никаких ненужных выделений памяти.

Бенчмарк

Давайте сравним создание списков с начальной емкостью и без нее.

Код бенчмарка. Нажмите, чтобы развернуть.

using System.Collections.Generic;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Jobs;

namespace ListBenchmark
{
    [ShortRunJob(RuntimeMoniker.Net48)]
    [ShortRunJob(RuntimeMoniker.NetCoreApp31)]
    [ShortRunJob(RuntimeMoniker.Net80)]
    [ShortRunJob(RuntimeMoniker.Net10_0)]
    [MemoryDiagnoser]
    [HideColumns("Job", "Error", "StdDev", "Gen0")]
    public class InitListBenchmark
    {
        [BenchmarkCategory("One")]
        [Benchmark]
        public List<int> InitList1()
        {
            return new List<int> {1};
        }

        [BenchmarkCategory("One")]
        [Benchmark]
        public List<int> InitListWithSize1()
        {
            return new List<int>(1) {1};
        }

        [BenchmarkCategory("Five")]
        [Benchmark]
        public List<int> InitList5()
        {
            return new List<int> {1, 2, 3, 4, 5};
        }
        
        [BenchmarkCategory("Five")]
        [Benchmark]
        public List<int> InitListWithSize5()
        {
            return new List<int>(5) {1, 2, 3, 4, 5};
        }
        
        [BenchmarkCategory("Ten")]
        [Benchmark]
        public List<int> InitList10()
        {
            return new List<int> {1, 2, 3, 4, 5, 6, 7, 8, 9, 0};
        }
        
        [BenchmarkCategory("Ten")]
        [Benchmark]
        public List<int> InitListWithSize10()
        {
            return new List<int>(10) {1, 2, 3, 4, 5, 6, 7, 8, 9, 0};
        }
    }
}

BenchmarkDotNet v0.15.6, Windows 10 (10.0.19045.6456/22H2/2022Update)
AMD Ryzen 7 7840H with Radeon 780M Graphics 3.80GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 10.0.100
[Host]                      : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v4
ShortRun-.NET 10.0          : .NET 10.0.0 (10.0.0, 10.0.25.52411), X64 RyuJIT x86-64-v4
ShortRun-.NET 8.0           : .NET 8.0.22 (8.0.22, 8.0.2225.52707), X64 RyuJIT x86-64-v4
ShortRun-.NET Core 3.1      : .NET Core 3.1.32 (3.1.32, 4.700.22.55902), X64 RyuJIT VectorSize=256
ShortRun-.NET Framework 4.8 : .NET Framework 4.8.1 (4.8.9310.0), X64 RyuJIT VectorSize=256

IterationCount=3  LaunchCount=1  WarmupCount=3

| Method             | Runtime            |      Mean | Allocated |
|--------------------|--------------------|----------:|----------:|
| InitList1          | .NET Framework 4.8 | 13.904 ns |      80 B |
| InitListWithSize1  | .NET Framework 4.8 |  6.658 ns |      72 B |
| InitList1          | .NET Core 3.1      | 11.091 ns |      72 B |
| InitListWithSize1  | .NET Core 3.1      |  7.407 ns |      64 B |
| InitList1          | .NET 8.0           | 10.084 ns |      72 B |
| InitListWithSize1  | .NET 8.0           |  6.838 ns |      64 B |
| InitList1          | .NET 10.0          |  8.170 ns |      72 B |
| InitListWithSize1  | .NET 10.0          |  6.638 ns |      64 B |
| InitList5          | .NET Framework 4.8 | 31.298 ns |     136 B |
| InitListWithSize5  | .NET Framework 4.8 | 12.013 ns |      88 B |
| InitList5          | .NET Core 3.1      | 26.466 ns |     128 B |
| InitListWithSize5  | .NET Core 3.1      |  9.446 ns |      80 B |
| InitList5          | .NET 8.0           | 23.714 ns |     128 B |
| InitListWithSize5  | .NET 8.0           | 15.587 ns |      80 B |
| InitList5          | .NET 10.0          | 20.002 ns |     128 B |
| InitListWithSize5  | .NET 10.0          |  8.712 ns |      80 B |
| InitList10         | .NET Framework 4.8 | 53.488 ns |     225 B |
| InitListWithSize10 | .NET Framework 4.8 | 18.185 ns |     104 B |
| InitList10         | .NET Core 3.1      | 44.371 ns |     216 B |
| InitListWithSize10 | .NET Core 3.1      | 12.496 ns |      96 B |
| InitList10         | .NET 8.0           | 38.707 ns |     216 B |
| InitListWithSize10 | .NET 8.0           | 12.024 ns |      96 B |
| InitList10         | .NET 10.0          | 33.854 ns |     216 B |
| InitListWithSize10 | .NET 10.0          | 15.822 ns |      96 B |

Когда мы устанавливаем начальную емкость, это не приводит к ненужным выделениям памяти, и мы видим лучшую производительность. И нет избыточного трафика памяти. Чем больше элементов мы добавляем в список, тем большую разницу мы видим в бенчмарках.

Анализатор

Если производительность критична для вашего проекта, вы должны обращать внимание на эти ситуации. Автоматическая диагностика может вам помочь. Я поддерживаю набор диагностических инструментов на основе Roslyn - Collections.Analyzer, и теперь он может обнаруживать списки с инициализатором коллекции и без начальной емкости.

Важно понимать, что анализатор устанавливает только начальный размер коллекции, чтобы избежать лишних аллокаций на начальном этапе заполнения коллекции. Он не может предсказать, как изменится размер коллекции в будущем.

Ссылки

Dapper: How caching can be harmful

Sergey Rogatnev — Sat, 06 Sep 2025 00:00:00 GMT

Dapper is a popular library that allows mapping objects from a database to C# types. Unlike Entity Framework, it is not a full-fledged ORM, but it is very popular due to its minimalism. In this article, I will explain how the default behavior can lead to a significant increase in memory consumption.

Profiling

This story began with one application at work. Metrics showed that over time it consumed more and more memory, although there were no obvious reasons for it. I collected an application dump and opened it in a profiler.

The problem was visible almost immediately — the application was holding 2 gigabytes of some strings in memory, related to Dapper. The strings themselves contained the body of the SQL query. Let's study what objects in memory they are associated with.

Dapper internals

The profiler points to the SqlMapper.Identity type and the associated SqlMapper.CacheInfo. From the name, it's obvious that it is about caching. Let's take a closer look at the creation of the SqlMapper.Identity type during query execution:

  private static async Task<int> ExecuteImplAsync(
    IDbConnection cnn,
    CommandDefinition command,
    object? param)
  {
    SqlMapper.CacheInfo cacheInfo = SqlMapper.GetCacheInfo(new SqlMapper.Identity(command.CommandText, new CommandType?(command.CommandTypeDirect), cnn, (Type) null, param?.GetType()), param, command.AddToCache);
    // ...
  }

As we can see, at the beginning of the method, we try to get something from the cache using SqlMapper.Identity as a key, which contains the full text of the query in command.CommandText and other parameters.

The type stored in the cache is SqlMapper.CacheInfo:

  private class CacheInfo
  {
    private int hitCount;
    public SqlMapper.DeserializerState Deserializer { get; set; }
    public Func<DbDataReader, object>[]? OtherDeserializers { get; set; }
    public Action<IDbCommand, object?>? ParamReader { get; set; }
    public int GetHitCount() => Interlocked.CompareExchange(ref this.hitCount, 0, 0);
    public void RecordHit() => Interlocked.Increment(ref this.hitCount);
  }

This is a set of different deserializers associated with a specific SQL query, which allows Dapper to reuse objects for similar queries, speeding up data materialization.

A fairly reasonable optimization. But why is our application holding such a large cache?

SQl + json = 🚩

The problem is how we construct the SQL query. For example, the method for getting users by a list of identifiers looks like this:

public async Task<ICollection<string>> SearchAsync(
    ThemeSearchRequest searchRequest, 
    int skip = 0,
    int take = int.MaxValue, 
    TimeSpan? timeout = null)
{
    var selectScript = @$"SELECT theme_base 
                          FROM [dbo].Themes 
                          {searchRequest.ToWhereExpression()}
                          GROUP BY theme_base
                          ORDER BY MAX(count_base) DESC, theme_base
                          OFFSET {skip} ROWS 
                          FETCH NEXT {take} ROWS ONLY";
    
        await using var connection = new SqlConnection(this.connectionString);
        
        var result = (await connection.QueryAsync<string>(
            selectScript,
            searchRequest.ToParametersWithValues(),
            commandTimeout: (int)(timeout?.TotalSeconds ?? DefaultTimeout.TotalSeconds))).AsList();
        
        return result;
}

The SearchAsync method forms a dynamic query to the database — some search conditions, pagination. And that's the problem. Almost every query will be unique, and according to Dapper's basic logic, it will be cached for fast materialization in the future.

The same is written in the documentation:

Dapper caches information about every query it runs, this allows it to materialize objects quickly and process parameters quickly. The current implementation caches this information in a ConcurrentDictionary object. Statements that are only used once are routinely flushed from this cache. Still, if you are generating SQL strings on the fly without using parameters it is possible you may hit memory issues.

Dapper caching

Let's take a closer look at the caching mechanism in Dapper. We have already found out that each SQL query is used as a key and stores additional information for fast materialization of objects. Will this cache grow indefinitely? Let's look at the SqlMapper code:

private static bool TryGetQueryCache(Identity key, [NotNullWhen(true)] out CacheInfo? value)
{
    if (_queryCache.TryGetValue(key, out value!))
    {
        value.RecordHit();
        return true;
    }
    value = null;
    return false;
}

The TryGetQueryCache method searches for data in the cache and, if successful, increments the hit counter — the number of times the data has been returned for this key.

private const int COLLECT_PER_ITEMS = 1000;
private static void SetQueryCache(Identity key, CacheInfo value)
{
    if (Interlocked.Increment(ref collect) == COLLECT_PER_ITEMS)
    {
        CollectCacheGarbage();
    }
    _queryCache[key] = value;
}

The SetQueryCache method tries to add data to the cache until it reaches a size of 1000 elements. When this limit is reached, the CollectCacheGarbage() method is called:

private const int COLLECT_HIT_COUNT_MIN = 0;
private static void CollectCacheGarbage()
{
    try
    {
        foreach (var pair in _queryCache)
        {
            if (pair.Value.GetHitCount() <= COLLECT_HIT_COUNT_MIN)
            {
                _queryCache.TryRemove(pair.Key, out var _);
            }
        }
    }
    finally
    {
        Interlocked.Exchange(ref collect, 0);
    }
}

It tries to remove all cached items that have never been accessed. In this process, the GetHitCount() method resets the internal hit counter:

public int GetHitCount() { return Interlocked.CompareExchange(ref hitCount, 0, 0); }

Thus, after CollectCacheGarbage() is run, the value of all hitCounts is reset, which allows finding unused elements during the next cleanup. But in the case of active use of dynamic SQL queries, it is highly likely that all queries will be used once and will be constantly evicted from the cache.

Using one-time queries not only hits your application's memory but also creates an additional load on the SQL server. It will have to parse, compile, and build an execution plan for each new query.

Solution

The correct solution here would be to use parameterized queries so that a single query will be reused many times, including on the SQL server:

public async Task<ICollection<TaskRules>> GetTaskRulesAsync(long taskId)
{
    var sql = $@"SELECT * FROM TaskRules WHERE TaskID = @taskId";
    await using var connection = new SqlConnection(this.connectionString);
    await connection.OpenAsync();
    var result = await connection
        .QueryAsync<TaskRules>(sql, new { taskId }, commandTimeout: 180);

    return result.AsList();
}

The GetTaskRulesAsync method uses a parameterized SQL query, where data is selected by @taskId. This allows using caching at all levels — in the application and on the SQL server.

A quick solution might be to disable caching for a specific query — this can be done by managing CommandFlags when creating the command:

new CommandDefinition(sql, CommandFlags.NoCache)

This way, "one-time" queries will not get into the cache and clutter up the memory.

Conclusion

Many solutions try to optimize frequently used scenarios through strict rules or some of their own heuristics. Such important rules are usually described somewhere prominently. In Dapper's case — right in the Readme.md.

Recommendations

Perform periodic profiling, see how applications use memory. For example, using dotMemory.
Use parameterized queries for working with SQL.
If any solution uses caching, make sure it is useful for you.

Паттерны: Спецификация

Сергей Рогатнев — Fri, 29 Aug 2025 00:00:00 GMT

Паттерн Спецификация (Specification) объединяет в себе доменный подход к построению приложений и Entity Framework. Этот паттерн создан для управления бизнес-правилами и соединяет наш код с ними. Эта статья показывает пример реализации этого паттерна на базе Entity Framework.

Для начала опишем нашу модель:

public sealed class User
{
    public User()
    {
        Contacts = new List<Contact>();
    }
    public int Id { get; set; }

    public string Login { get; set; }

    public bool IsActive { get; set; }

    public ICollection<Contact> Contacts { get; }
}

public abstract class Contact
{
    public int Id { get; set; }

    public bool IsActive { get; set; }
}

public class Phone : Contact
{
    public string PhoneCode { get; set; }
    public string PhoneNumber { get; set; }
}

public class Email : Contact
{
    public string Value { get; set; }
}

Она достаточно простая, но подходит нам в качестве примера. Теперь добавим немного магии Entity Framework для создания контекста данных:

public sealed class Context : DbContext
{
    public Context(DbContextOptions builderOptions)
        :base(builderOptions)
    {
        
    }
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Entity<User>().HasMany(o => o.Contacts).WithOne();
        modelBuilder.Entity<Contact>()
            .HasDiscriminator<int>("ContactType")
            .HasValue<Phone>(1)
            .HasValue<Email>(2);
    }
}

Теперь мы можем использовать SQL Server в качестве хранилища.

Хорошо спроектированные приложения разделяют хранилище и доменную модель, поэтому мы добавим репозиторий для нашего класса User:

public interface IUserRepository
{
    void Add(User user);
    User Get(int id);
}

public sealed class UserRepository : IUserRepository
{
    private readonly Context _context;

    public UserRepository(Context context)
    {
        _context = context;
    }

    public void Add(User user)
    {
        _context.Set<User>().Add(user);
    }

    public User Get(int id)
    {
        return _context.Set<User>().FirstOrDefault(o => o.Id == id);
    }
}

Сейчас это выглядит как стандартное приложение, ничего особенного. Самое интересное начинается, когда нам требуется реализовать различные запросы в наше хранилище. Давайте рассмотрим самые распространенные способы.

Фильтры

Для примера давайте создадим несколько фильтров:

Найти всех пользователей с активными телефонами
Найти всех пользователей по префиксу логина
Найти всех пользователей по телефонному номеру

Путь IQueryable

Самый простой способ - предоставить метод репозитория, который возвращает IQueryable<User> и позволить разработчикам запрашивать любые данные:

public interface IUserRepository
{
    void Add(User user);
    User Get(int id);
    IQueryable<User> Query();
}

public sealed class UserRepository : IUserRepository
{
    private readonly Context _context;

    public UserRepository(Context context)
    {
        _context = context;
    }

    public void Add(User user)
    {
        _context.Set<User>().Add(user);
    }

    public User Get(int id)
    {
        return _context.Set<User>().FirstOrDefault(o => o.Id == id);
    }

    public IQueryable<User> Query()
    {
        return _context.Set<User>();
    }
}

С методом Query мы можем реализовать наши фильтры:

public static void Search(IUserRepository repository)
{
    var users1 = repository.Query()
        .Where(o => o.Contacts.Any(c => c is Phone && c.IsActive))
        .ToArray();

    var users2 = repository.Query()
        .Where(o => o.Login.StartsWith("log"))
        .ToArray();

    var users3 = repository.Query()
        .Where(o => o.Contacts.Any(c => c is Phone && (c as Phone).PhoneNumber == "111-22-33"))
        .ToArray();
}

Это быстрое и простое решение, но имеющее серьезные недостатки:

Нам нужно повторять код фильтра, если нужно его переиспользовать в другом месте. Можно сделать изменение в одном месте и забыть в другом — вот они, недостатки дублирования кода.
Бизнес-логика (наши фильтры) распределены по коду. Мы не можем просто выписать все правила, т.к. они находятся в разных частях приложения.
Сложно тестировать. Мы не можем проверить фильтры отдельно от хранилища.

Методы расширения

Можно попробовать устранить недостатки предыдущего решения и собрать все фильтры в одном классе в виде методов расширений:

public static class UserQueryExtensions
{
    public static IEnumerable<User> FindWithActivePhones(this IQueryable<User> query)
    {
        return query.Where(o => o.Contacts.Any(c => c is Phone && c.IsActive))
            .AsEnumerable();
    }

    public static IEnumerable<User> FindWithLoginPrefix(this IQueryable<User> query, string prefix)
    {
        return query.Where(o => o.Login.StartsWith(prefix))
            .AsEnumerable();
    }

    public static IEnumerable<User> FindWithPhoneNumber(this IQueryable<User> query, string phoneNumber)
    {
        return query.Where(o => o.Contacts.Any(c => c is Phone && (c as Phone).PhoneNumber == phoneNumber))
            .AsEnumerable();
    }
}

public static void Search(IUserRepository repository)
{
    var users1 = repository.Query().FindWithActivePhones();

    var users2 = repository.Query().FindWithLoginPrefix("log");

    var users3 = repository.Query().FindWithPhoneNumber("111-22-33");
}

Выглядит лучше, теперь вся бизнес-логика (фильтры) находятся в одном месте и их можно протестировать:

[Test]
public void FindWithActivePhonesTest()
{
    var user = new User
    {
        Id = 1,
        Login = "login"
    };
    user.Contacts.Add(new Phone { IsActive = true, PhoneNumber = "123-321" });
    
    var queryable = new[] { user }.AsQueryable();

    var result = queryable.FindWithActivePhones();

    CollectionAssert.AreEquivalent(new[] { 1 }, result.Select(o => o.Id));
}

Но наш репозиторий всё еще содержит метод Query, что нехорошо, это может привести к неконтролируемому использованию. Можно переместить всю логику внутрь репозитория:

Фильтры в репозитории

Добавим все фильтр-методы в сам репозиторий:

public interface IUserRepository
{
    void Add(User user);
    User Get(int id);
    IEnumerable<User> FindWithActivePhones();
    IEnumerable<User> FindWithLoginPrefix(string prefix);
    IEnumerable<User> FindWithPhoneNumber(string phoneNumber);
}

public sealed class UserRepository : IUserRepository
{
    private readonly Context _context;

    public UserRepository(Context context)
    {
        _context = context;
    }

    public void Add(User user)
    {
        _context.Set<User>().Add(user);
    }

    public User Get(int id)
    {
        return _context.Set<User>().FirstOrDefault(o => o.Id == id);
    }

    public IEnumerable<User> FindWithActivePhones()
    {
        return _context.Set<User>().Where(o => o.Contacts.Any(c => c is Phone && c.IsActive))
            .AsEnumerable();
    }

    public IEnumerable<User> FindWithLoginPrefix(string prefix)
    {
        return _context.Set<User>().Where(o => o.Login.StartsWith(prefix))
            .AsEnumerable();
    }

    public IEnumerable<User> FindWithPhoneNumber(string phoneNumber)
    {
        return _context.Set<User>().Where(o => o.Contacts.Any(c => c is Phone && (c as Phone).PhoneNumber == phoneNumber))
            .AsEnumerable();
    }
}

public static void Search(IUserRepository repository)
{
    var users1 = repository.FindWithActivePhones();

    var users2 = repository.FindWithLoginPrefix("log");

    var users3 = repository.FindWithPhoneNumber("111-22-33");
}

Мы избавились от опасного метода Query. Но всё еще есть сложности с тестированием — методы сильно связаны с хранилищем и Entity Framework. Так же, наши фильтры могут использоваться только для доступа к хранилищу. А что, если мы хотим проверить вновь создаваемые сущности этими бизнес-правилами? Сейчас это невозможно.

На самом деле, мы бы могли остановиться на этом решении, его достаточно в 99% случаев.

Но если вы используете Domain-Driven development (DDD), Entity Framework (или другую ORM) и активно используете юнит-тесты, то вам может подойти следующий подход.

Спецификации

Вначале давайте опишем требования, которые для нас важны:

Хранить бизнес-правила в одном месте и не дублировать их
Фильтры отделены от хранилища (могут быть использованы вне репозитория)
Фильтры можно тестировать отдельно

Ключевая сущность паттерна - это спецификация, специальный объект с бизнес-правилом.

public interface ISpecification<T>
{
    Expression<Func<T, bool>> IsSatisfiedBy { get; }
}

Где T - наша бизнес сущность (User как в примерах выше). В репозиторий добавляется метод, который работает со спецификацией:

public interface IUserRepository
{
    void Add(User user);
    User Get(int id);
    IEnumerable<User> Get(ISpecification<User> specification);
}

public sealed class UserRepository : IUserRepository
{
    private readonly Context _context;

    public UserRepository(Context context)
    {
        _context = context;
    }

    public void Add(User user)
    {
        _context.Set<User>().Add(user);
    }

    public User Get(int id)
    {
        return _context.Set<User>().FirstOrDefault(o => o.Id == id);
    }

    public IEnumerable<User> Get(ISpecification<User> specification)
    {
        return _context.Set<User>()
            .Where(specification.IsSatisfiedBy)
            .AsEnumerable();
    }
}

Entity Framework позволяет нам использовать концепцию LINQ to SQL через методы расширения. Нам интересен метод Where с предикатом фильтра:

public static IQueryable<TSource> Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, bool>> predicate)

Реализуем наши бизнес-правила (спецификации):

public class ActivePhonesSpecification : ISpecification<User>
{
	public Expression<Func<User, bool>> IsSatisfiedBy =>
		o => o.Contacts.Any(c => c is Phone && c.IsActive);
}

public class LoginPrefixSpecification : ISpecification<User>
{
	public LoginPrefixSpecification(string prefix)
	{
		IsSatisfiedBy = o => o.Login.StartsWith(prefix);
	}
	public Expression<Func<User, bool>> IsSatisfiedBy { get; }
}

public class PhoneNumberSpecification:ISpecification<User>
{
	public PhoneNumberSpecification(string phoneNumber)
	{
		IsSatisfiedBy = o => o.Contacts.Any(c => c is Phone && (c as Phone).PhoneNumber == phoneNumber);
	}
	public Expression<Func<User, bool>> IsSatisfiedBy { get; }
}

Мы описали все правила в одном месте и они отделены от хранилища - работают только с доменной сущностью.

public static void Search(IUserRepository repository)
{
	var users1 = repository.Get(new ActivePhonesSpecification());

	var users2 = repository.Get(new LoginPrefixSpecification("log"));

	var users3 = repository.Get(new PhoneNumberSpecification("111-22-33"));
}

Тестирование:

[Test]
public void FindWithActivePhonesTest()
{
	var user = new User
	{
		Id = 1,
		Login = "login"
	};
	user.Contacts.Add(new Phone { IsActive = true, PhoneNumber = "123-321" });


	var queryable = new[] { user }.AsQueryable();

	var specification = new ActivePhonesSpecification();
	var result = queryable.Where(specification.IsSatisfiedBy);

	CollectionAssert.AreEquivalent(new[] { 1 }, result.Select(o => o.Id));
}

Работа с правилами без хранилища:

[Test]
public void FindWithActivePhonesTest()
{
	var user = new User
	{
		Id = 1,
		Login = "login"
	};
	user.Contacts.Add(new Phone { IsActive = true, PhoneNumber = "123-321" });

	var specification = new ActivePhonesSpecification();

	Assert.IsTrue(specification.IsSatisfiedBy.Compile().Invoke(user));
}

Как улучшение, мы можем скомпилировать метод из выражения IsSatisfiedBy.

Заключение

DDD описывает модели, репозитории и правила
Entity Framework и LINQ позволяют организовать простой доступ к данным
Спецификации хранят правила отдельно от уровня работы с данными

Ссылки

Dapper: как кеширование может принести вред

Сергей Рогатнев — Sun, 24 Aug 2025 00:00:00 GMT

Dapper — популярная библиотека, которая позволяет делать маппинг объектов из базы данных в типы C#. В отличие от Entity Framework не является полноценной ORM, но пользуется большой популярностью за счет своей минималистичности. В этой статье я расскажу, как поведение по-умолчанию может привести к значительному росту потребления памяти.

Профилирование

Эта история началась с одного приложения на работе. Метрики показывали, что со временем оно потребляло всё больше и больше памяти, хотя явных причин на то не было. Я собрал дамп приложения и открыл его в профайлере.

Проблема была видна практически сразу — приложение держало в памяти 2 гигабайта каких-то строк, связанных с Dapper. Сами строки содержали в себе тело SQL-запроса. Давайте посмотрим, с какими объектами в памяти они ассоциированы.

Внутренности Dapper

Профайлер указывает нам на тип SqlMapper.Identity и связанынй с ним SqlMapper.CacheInfo. По названию очевидно, что это своего рода кеширование. Давайте ближе взглянем на создание типа SqlMapper.Identity в процессе выполнения запроса:

  private static async Task<int> ExecuteImplAsync(
    IDbConnection cnn,
    CommandDefinition command,
    object? param)
  {
    SqlMapper.CacheInfo cacheInfo = SqlMapper.GetCacheInfo(new SqlMapper.Identity(command.CommandText, new CommandType?(command.CommandTypeDirect), cnn, (Type) null, param?.GetType()), param, command.AddToCache);
    // ...
  }

Как мы видим, в самом начале метода мы пытаемся получить что-то из кэша используя для этого в качестве ключа SqlMapper.Identity, который в свою очередь содержит полный текст запроса command.CommandText и другие параметры.

Хранится в кеше тип SqlMapper.CacheInfo:

  private class CacheInfo
  {
    private int hitCount;
    public SqlMapper.DeserializerState Deserializer { get; set; }
    public Func<DbDataReader, object>[]? OtherDeserializers { get; set; }
    public Action<IDbCommand, object?>? ParamReader { get; set; }
    public int GetHitCount() => Interlocked.CompareExchange(ref this.hitCount, 0, 0);
    public void RecordHit() => Interlocked.Increment(ref this.hitCount);
  }

Это набор разных десериализаторов ассоциированных с конкретным SQL-запросом, что позволяет Dapper переиспользовать объекты для однотипных запросов ускоряя материализацию данных.

Довольно разумная оптимизация. Но почему же наше приложение держит такой большой кэш?

SQl + json = 🚩

Проблема в том, как именно мы составляем SQL запрос. Например, метод получения пользователей по списку идентификаторов выглядит так:

public async Task<ICollection<string>> SearchAsync(
    ThemeSearchRequest searchRequest, 
    int skip = 0,
    int take = int.MaxValue, 
    TimeSpan? timeout = null)
{
    var selectScript = @$"SELECT theme_base 
                          FROM [dbo].Themes 
                          {searchRequest.ToWhereExpression()}
                          GROUP BY theme_base
                          ORDER BY MAX(count_base) DESC, theme_base
                          OFFSET {skip} ROWS 
                          FETCH NEXT {take} ROWS ONLY";
    
        await using var connection = new SqlConnection(this.connectionString);
        
        var result = (await connection.QueryAsync<string>(
            selectScript,
            searchRequest.ToParametersWithValues(),
            commandTimeout: (int)(timeout?.TotalSeconds ?? DefaultTimeout.TotalSeconds))).AsList();
        
        return result;
}

Метод SearchAsync формирует динамический запрос к базе — какие-то поисковые условия, пагинация. И в этом и есть проблема. Почти каждый запрос будет уникальным, и согласно базовой логике Dapper он будет кешироваться для быстрой материализации в будущем.

Об этом же написано в документации:

Dapper caches information about every query it runs, this allows it to materialize objects quickly and process parameters quickly. The current implementation caches this information in a ConcurrentDictionary object. Statements that are only used once are routinely flushed from this cache. Still, if you are generating SQL strings on the fly without using parameters it is possible you may hit memory issues.

Кеширование Dapper

Давайте подробнее рассмотрим механизм кеширование в Dapper. Мы уже выяснили, что каждый SQL-запрос используется в качестве ключа и сохраняет дополнительную информацию для быстрой материализации объектов. Будет ли этот кэш расти бесконечно? Давайте взглянем на код SqlMapper:

private static bool TryGetQueryCache(Identity key, [NotNullWhen(true)] out CacheInfo? value)
{
    if (_queryCache.TryGetValue(key, out value!))
    {
        value.RecordHit();
        return true;
    }
    value = null;
    return false;
}

Метод TryGetQueryCache ищет данные в кэше и в случае успеха увеличивает счетчик попаданий — количество раз, котоыре данные возвращались по этому ключу.

private const int COLLECT_PER_ITEMS = 1000;
private static void SetQueryCache(Identity key, CacheInfo value)
{
    if (Interlocked.Increment(ref collect) == COLLECT_PER_ITEMS)
    {
        CollectCacheGarbage();
    }
    _queryCache[key] = value;
}

Метод SetQueryCache пытается добавить данные в кэш, пока он не достиг размера в 1000 элементов. В случае его достижения вызывается метод CollectCacheGarbage():

private const int COLLECT_HIT_COUNT_MIN = 0;
private static void CollectCacheGarbage()
{
    try
    {
        foreach (var pair in _queryCache)
        {
            if (pair.Value.GetHitCount() <= COLLECT_HIT_COUNT_MIN)
            {
                _queryCache.TryRemove(pair.Key, out var _);
            }
        }
    }
    finally
    {
        Interlocked.Exchange(ref collect, 0);
    }
}

Он пытается удалить все закешированные элементы, к которым ни разу не обращались. При этом, метод GetHitCount() обнуляет внутренний счетчик попаданий:

public int GetHitCount() { return Interlocked.CompareExchange(ref hitCount, 0, 0); }

Таким образом, после запуска CollectCacheGarbage() значение всех hitCount обнуляется, что позволяет найти неиспользуемые элементы при следующей очистке. Но в случае активного использования динамических SQL-запросов велика вероятность, что все запросы будут использоваться по 1 разу и постоянно будут вытесняться из кэша.

Использование одноразовых запросов бьет не только по памяти вашего приложения, но и создаёт дополнительную нагрузку на SQL-сервер. Ему придется парсить, компилировать и строить план выполнения для каждого нового запроса.

Решение

Корректным вариантом решения здесь было бы использование параметризованных, тогда один запрос будет переиспользоваться множество раз, в том числе и на SQL-сервере:

public async Task<ICollection<TaskRules>> GetTaskRulesAsync(long taskId)
{
    var sql = $@"SELECT * FROM TaskRules WHERE TaskID = @taskId";
    await using var connection = new SqlConnection(this.connectionString);
    await connection.OpenAsync();
    var result = await connection
        .QueryAsync<TaskRules>(sql, new { taskId }, commandTimeout: 180);

    return result.AsList();
}

В методе GetTaskRulesAsync используется параметризованный SQL-запрос, где выбираются данные по @taskId. Это позволяет эффективно использовать кеширование на всех уровнях — в приложении и SQL-сервере.

Быстрым решением может быть отключение кеширования для конкретного запроса — это можно сделать через управление CommandFlags при создании команды:

new CommandDefinition(sql, CommandFlags.NoCache)

Таким образом, "одноразовые" запросы не будут попадать в кэш и засорять память.

Заключение

Многие решения пытаются оптимизировать часто-используемые сценарии за счет строгих правил или каких-то своих эвристик. Такие важные правила обычно описаны где-то на видном месте. В случае в Dapper — сразу в Readme.md.

Пагинация: как правильно поделить данные по страницам

Сергей Рогатнев — Sat, 12 Jul 2025 00:00:00 GMT

Работая с большими списками данных, мы разбиваем их на страницы — так и пользователю удобнее, и не нагружает нашу систему. А значит вы наверняка решали задачу определения общего количества страниц. Давайте покажу вам один простой и элегантный способ.

Пагинация

В классическом виде задача звучит так: у нас есть всего TotalCount записей в базе данных, нужно вывести их постранично по BatchSize на страницу. Нужно определить количество страниц - PageCount. Для этого нужно поделить TotalCount на BatchSize и если результат получился дробным, то округлить его вверх.

| TotalCount | BatchSize | TotalCount/BatchSize | PageCount |
|------------|-----------|----------------------|----------:|
| 90         | 10        | 9                    |         9 |
| 99         | 10        | 9.9                  |        10 |
| 100        | 10        | 10                   |        10 |
| 101        | 10        | 10.1                 |        11 |

Math.Ceiling

В C# можно воспользоваться методом Math.Ceiling - он округляет вещественное число до ближайшего целого, которое больше либо равно переданному аргументу.

var PageCount = (int)Math.Ceiling((double)TotalCount / BatchSize);

Мы получим корректное значение. Но как вы заметили, нам вначале нужно преобразовать наши целые числа TotalCount, BatchSize в вещественные, вызвать метод, а потом обратно преобразовать результат в целочисленный.

Остаток от деления

Можно заметить, если TotalCount делится нацело на BatchSize, то результатом является просто частное TotalCount/BatchSize, иначе нужно добавить 1 к результату. Преобразуем нашу формулу:

var PageCount = TotalCount / BatchSize + (TotalCount % BatchSize == 0 ? 0 : 1);

Мы избавились от преобразований типа и вызова метода, но добавился один тернарный оператор. Можно ли сделать еще проще? Оказывается, можно.

Целочисленное деление

Как мы знаем, целочисленное деление всегда даёт округление результата к меньшему либо равному значению. Давайте воспользуемся этой особенностью и рассмотрим следующее выражение:

var Add = (BatchSize - 1) / BatchSize;

Числитель у нас всегда меньше знаменателя, поэтому результат целочисленного деления всегда будет равен 0. Добавим это выражение к частному TotalCount / BatchSize:

var PageCount = TotalCount / BatchSize + (BatchSize - 1) / BatchSize;

По правилам целочисленной арифметики второе слагаемое всегда равно 0 и оно не влияет на сумму. Давайте внесем его под общий знаменатель:

var PageCount = (TotalCount + BatchSize - 1) / BatchSize;

Это и есть наша элегантная формула деления с округлением вверх. Почему она работает?

Давайте рассмотрим 2 случая:

TotalCount делится нацело на BatchSize, тогда TotalCount / BatchSize даст нужный нам PageCount, а (BatchSize - 1) / BatchSize даст 0 и не повлияет на результат.
TotalCount при делении на BatchSize даёт остаток R, тогда TotalCount / BatchSize даст значение PageCount - 1. И у нас остаётся выражение (R + BatchSize - 1) / BatchSize, где R по определению всегда больше 1 и меньше BatchSize. При любых значениях R результат целочисленного деления будет равен 1. Таким образом, в итоге получим значение PageCount.

Бенчмарк

Давайте ряди любопытства сравним все 3 способа.

Код бенчмарка. Нажмите, чтобы развернуть.

using BenchmarkDotNet.Attributes;

namespace Paging;

public class Benchmark
{
    [Params(99)]
    public int TotalCount;

    [Params(10)]
    public int BatchSize;

    [Params(10000)]
    public int Iterations;

    [Benchmark]
    public int MathCeiling()
    {
        var result = 0;
        for (int i = 0; i < Iterations; i++)
            result += (int)Math.Ceiling((double)TotalCount / BatchSize);
        return result;
    }

    [Benchmark]
    public int Mod()
    {
        var result = 0;
        for (int i = 0; i < Iterations; i++)
            result += TotalCount / BatchSize + (TotalCount % BatchSize == 0 ? 0 : 1);
        return result;
    }

    [Benchmark]
    public int Div()
    {
        var result = 0;
        for (int i = 0; i < Iterations; i++)
            result += (TotalCount + BatchSize - 1) / BatchSize;
        return result;
    }
}

Результаты:

BenchmarkDotNet v0.15.2, Windows 10 (10.0.19045.6093/22H2/2022Update)
AMD Ryzen 7 7840H with Radeon 780M Graphics 3.80GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 8.0.412
  [Host]     : .NET 8.0.18 (8.0.1825.31117), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  DefaultJob : .NET 8.0.18 (8.0.1825.31117), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI


| Method      | TotalCount | BatchSize | Iterations |     Mean |     Error |    StdDev |
|-------------|------------|-----------|------------|---------:|----------:|----------:|
| MathCeiling | 99         | 10        | 10000      | 2.298 us | 0.0042 us | 0.0037 us |
| Mod         | 99         | 10        | 10000      | 4.517 us | 0.0597 us | 0.0559 us |
| Div         | 99         | 10        | 10000      | 2.285 us | 0.0455 us | 0.0425 us |

Еще одно подтверждение бессмысленности этих измерений — это необходимость нескольких тысяч итераций, иначе значения неотличимы от нуля. Тем не менее удивительно, что первый и третий варианты показали практически идентичный результат.

Заключение

Данная формула — хорошая демонстрация особенностей целочисленной арифметики, которая немного отличается от обычной. Можно пользоваться этими возможностями, но не в ущерб понятности.

И да, важно, что данная формула работает только для положительных чисел.

String of Digits

Sergey Rogatnev — Sat, 05 Jul 2025 00:00:00 GMT

A popular task is to check if a string contains only digits. For example, you need to check if the user entered the correct phone number, index or a tax code of an organization. There are several ways to solve this task, which differ in their efficiency. Let's take a look at the most popular ones.

Regex

Probably the most popular way to solve this task is to use a regular expression. It's straightforward and easy to use an expression ^[0-9]*$ (or ^\d*$).

Below is a naive implementation of a regular expression check:

Regex regex = new Regex("^[0-9]*$");
var value = "123456789000";
var isValid = regex.IsMatch(value);

I'm sure someone sees the problem. This implementation is only suitable for a one-time launch. In production code, when you check thousands of strings, this solution will not be efficient. .NET provides the ability to compile a regular expression at runtime, by using the RegexOptions.Compiled option:

Regex regex = new Regex("^[0-9]*$", RegexOptions.Compiled);
var value = "123456789000";
var isValid = regex.IsMatch(value);

Calling a constructor with this option will generate IL code that will be called through DynamicMethod inside Regex.IsMatch, which will be faster than the usual regular expression processing. The downside is that it takes longer to create a Regex object due to the time spent on compilation at runtime, but this quickly pays off with repeated use.

Let's compare both solutions.

Benchmark code. Click to expand.

[MemoryDiagnoser]
[SimpleJob(RuntimeMoniker.Net90)]
[SimpleJob(RuntimeMoniker.Net60)]
[SimpleJob(RuntimeMoniker.NetCoreApp31)]
[SimpleJob(RuntimeMoniker.Net48)]
[HideColumns("Job", "Error", "StdDev", "Gen0")]
public partial class DigitsBenchmarks
{
    private static string value = "123456789000";

    private static readonly Regex regex = new Regex("^[0-9]*$");
    private static readonly Regex compiledRegex = new Regex("^[0-9]*$", RegexOptions.Compiled);

    [Benchmark]
    public bool Regex()
    {
        return regex.IsMatch(value);
    }
    
    [Benchmark]
    public bool CompiledRegex()
    {
        return compiledRegex.IsMatch(value);
    }
}

Results:

Method	Runtime	Mean	Median	Allocated
Regex	.NET Framework 4.8	165.4417 ns	166.2537 ns	-
CompiledRegex	.NET Framework 4.8	115.9377 ns	115.9720 ns	-
Regex	.NET Core 3.1	118.1540 ns	118.1887 ns	-
CompiledRegex	.NET Core 3.1	89.7392 ns	89.6514 ns	-
Regex	.NET 6.0	57.8247 ns	57.8031 ns	-
CompiledRegex	.NET 6.0	21.2952 ns	21.2616 ns	-
Regex	.NET 9.0	47.2579 ns	47.3506 ns	-
CompiledRegex	.NET 9.0	24.2419 ns	24.2547 ns	-

The advantage of using compiled expressions is quite obvious. Also, with each new version of .NET, the contribution of developers to performance is more visible. This is another argument in favor of upgrading to modern versions of the .NET Framework.

Regex source generators

Again, compiling regular expressions has one drawback - creating a Regex object at runtime will take some time. Is it possible to get rid of this?

Starting with .NET 7, this capability is available through source generators. Strictly speaking, source generators appeared in .NET 5, but the regular expression solution was implemented only in the seventh version.

Source generators allow you to create C# code at compile time, which means you can view and debug it as if it was your own code. And regular expressions can be converted to C# code at compile time! .NET has a special attribute for this - GeneratedRegex:

namespace DigitBenchmark
{
    public partial class DigitsBenchmarks
    {
        private static readonly Regex generatedRegex = GenerateRegex();
        
        [GeneratedRegex("^[0-9]*$")]
        private static partial Regex GenerateRegex();
    }
}

Let's figure out what's going on here.

First, we need to mark our DigitsBenchmarks class as partial, since some of the generated code for this class will be in another file. Next we need to create a partial method that will return an object of type Regex and mark it with the GeneratedRegex attribute specifying the regular expression pattern. You don't need to specify the RegexOptions.Compiled option, it will be ignored.

The implementation of the GenerateRegex method will be in another file. You can find it in the project and view the source code:

namespace DigitBenchmark
{
    partial class DigitsBenchmarks
    {
        /// <remarks>
        /// Pattern:<br/>
        /// <code>^[0-9]*$</code><br/>
        /// Explanation:<br/>
        /// <code>
        /// ○ Match if at the beginning of the string.<br/>
        /// ○ Match a character in the set [0-9] atomically any number of times.<br/>
        /// ○ Match if at the end of the string or if before an ending newline.<br/>
        /// </code>
        /// </remarks>
        [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Text.RegularExpressions.Generator", "8.0.12.21506")]
        private static partial global::System.Text.RegularExpressions.Regex GenerateRegex() => global::System.Text.RegularExpressions.Generated.GenerateRegex_0.Instance;
    }
}

As you can see, the file with the same class was automatically created and contains the implementation of our method for generating a regular expression.

And then we can use this Regex object as usual. Since this is real C# code, there is no need to generate anything at runtime, so there is no point in specifying the RegexOptions.Compiled option.

What benefit do we get from this? My benchmarks do not include .NET 7 and 8, let's compare the performance of the latest one at the moment:

Method	Runtime	Mean	Median	Allocated
Regex	.NET 9.0	47.2579 ns	47.3506 ns	-
CompiledRegex	.NET 9.0	24.2419 ns	24.2547 ns	-
GeneratedRegex	.NET 9.0	17.2548 ns	17.2603 ns	-

We see that the time has been reduced by almost 30%! The compiler has much more opportunity to optimize the source code at the compilation stage than at runtime.

char.IsDigit

Another popular way is to use the static char.IsDigit method in combination with the LINQ All method:

var value = "123456789000";
var isValid = value.All(char.IsDigit);

Let's check how good this method is in terms of performance.

Benchmark code. Click to expand.

[MemoryDiagnoser]
[SimpleJob(RuntimeMoniker.Net90)]
[SimpleJob(RuntimeMoniker.Net60)]
[SimpleJob(RuntimeMoniker.NetCoreApp31)]
[SimpleJob(RuntimeMoniker.Net48)]
[HideColumns("Job", "Error", "StdDev", "Gen0")]
public partial class DigitsBenchmarks
{
    [Benchmark]
    public bool LinqCharIsDigit()
    {
        return value.All(char.IsDigit);
    }
}

Results:

Method	Runtime	Mean	Median	Allocated
LinqCharIsDigit	.NET Framework 4.8	92.1679 ns	92.2549 ns	96 B
LinqCharIsDigit	.NET Core 3.1	72.0987 ns	72.6419 ns	96 B
LinqCharIsDigit	.NET 6.0	74.2609 ns	74.4256 ns	96 B
LinqCharIsDigit	.NET 9.0	31.0294 ns	31.0501 ns	32 B

And let's compare this method with previous solutions.

If in older versions of the framework, LINQ validation and the IsDigit method has an advantage over regular expressions, then later we see that such an implementation starts to lose.

Also, please note that each call results in the allocation of additional memory. This value consists of two parts:

Creating a lambda expression in a method parameter All(c => char.IsDigit(c)).
Creating an iterator inside the All method.

It is noteworthy that .NET 9 allocates three times less memory. Before .NET 9, the All method consisted of a foreach loop with a condition:

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
  //...
  foreach (TSource source1 in source)
  {
    if (!predicate(source1))
      return false;
  }
  return true;
}

But in .NET 9, an important optimization was added:

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
  //...
  ReadOnlySpan<TSource> span;
  if (source.TryGetSpan<TSource>(out span))
  {
    ReadOnlySpan<TSource> readOnlySpan = span;
    for (int index = 0; index < readOnlySpan.Length; ++index)
    {
      TSource source1 = readOnlySpan[index];
      if (!predicate(source1))
        return false;
    }
  }
  else
  {
    foreach (TSource source2 in source)
    {
      if (!predicate(source2))
        return false;
    }
  }
  return true;
}

Instead of an unconditional foreach loop, the All method tries to get a ReadOnlySpan - a read-safe contiguous block of memory - from the source. And then a simple for loop is used, which does not lead to the creation of an iterator, reducing the amount of additional memory. You can get rid of this completely by rewriting the All method to a regular loop:

public bool ForIsDigit()
{
    for (var i = 0; i < value.Length; i++)
    {
        if (!char.IsDigit(value[i]))
            return false;
    }

    return true;
}

In addition to the absence of unnecessary memory traffic, this solution is rapid.

What is a digit?

It seems that we have found the optimal solution for checking a string for the presence of only digits. But try to guess what the following code will output:

Console.WriteLine(char.IsDigit('0'));
Console.WriteLine(char.IsDigit('a'));
Console.WriteLine(char.IsDigit('٨'));
Console.WriteLine(char.IsDigit('৯'));

Click to find out the answer.

Console.WriteLine(char.IsDigit('0')); //True
Console.WriteLine(char.IsDigit('a')); //False
Console.WriteLine(char.IsDigit('٨')); //True
Console.WriteLine(char.IsDigit('৯')); //True

I think the result surprises you. But there is nothing unusual about it, the IsDigit method considers as digits not only the usual symbols from the set 0-9, but also all other symbols that are related to digits in the Unicode encoding. And there are actually a lot of them. This can be a problem if you rely on such a check in your business code.

I think this is the reason for the new char.IsAsciiDigit method to appear starting with .NET 7. Now it really only checks characters from the 0-9 set.

Its implementation is very similar to manually checking each character in the loop, let's compare both solutions:

[Benchmark]
public bool ForCompare()
{
    for (var i = 0; i < value.Length; i++)
    {
        if (value[i] < '0' || value[i] > '9')
            return false;
    }

    return true;
}

[Benchmark]
public bool ForIsAsciiDigit()
{
    for (var i = 0; i < value.Length; i++)
    {
        if (!char.IsAsciiDigit(value[i]))
            return false;
    }

    return true;
}

Method	Runtime	Mean	Median	Allocated
ForCompare	.NET 9.0	4.8587 ns	4.8656 ns	-
ForIsAsciiDigit	.NET 9.0	4.7515 ns	4.4976 ns	-

Both methods show equivalent results.

Conclusion

We've looked at several different ways to check whether a string consists only of digits or not. And it's important to understand the specifics of how some of them work, because in addition to trivial performance issues, you can get errors in your business logic if you don't check your input data well enough.

Recommendations:

If you write your applications for .NET 7 or higher, then use the generated regular expressions. Otherwise, specify the RegexOptions.Compiled option.
If you write your applications for .NET 7, use the char.IsAsciiDigit method to check characters. Otherwise, it is better to write the check yourself.

Links

Full benchmark code. Click to expand.

using System.Linq;
using System.Text.RegularExpressions;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Jobs;

namespace DigitBenchmark
{
    [MemoryDiagnoser]
    [SimpleJob(RuntimeMoniker.Net90)]
    [SimpleJob(RuntimeMoniker.Net60)]
    [SimpleJob(RuntimeMoniker.NetCoreApp31)]
    [SimpleJob(RuntimeMoniker.Net48)]
    [HideColumns("Job", "Error", "StdDev", "Gen0")]
    public partial class DigitsBenchmarks
    {
        private static string value = "123456789000";

        private static readonly Regex regex = new Regex("^[0-9]*$");
        private static readonly Regex compiledRegex = new Regex("^[0-9]*$", RegexOptions.Compiled);
        private static readonly Regex generatedRegex = GenerateRegex();

        [GeneratedRegex("^[0-9]*$")]
        private static partial Regex GenerateRegex();

        [Benchmark]
        public bool Regex()
        {
            return regex.IsMatch(value);
        }
        
        [Benchmark]
        public bool CompiledRegex()
        {
            return compiledRegex.IsMatch(value);
        }

        [Benchmark]
        public bool GeneratedRegex()
        {
            return generatedRegex.IsMatch(value);
        }

        [Benchmark]
        public bool LinqCharIsDigit()
        {
            return value.All(char.IsDigit);
        }

        [Benchmark]
        public bool ForCompare()
        {
            for (var i = 0; i < value.Length; i++)
            {
                if (value[i] < '0' || value[i] > '9')
                    return false;
            }

            return true;
        }

        [Benchmark]
        public bool ForIsDigit()
        {
            for (var i = 0; i < value.Length; i++)
            {
                if (!char.IsDigit(value[i]))
                    return false;
            }

            return true;
        }

        [Benchmark]
        public bool ForIsAsciiDigit()
        {
            for (var i = 0; i < value.Length; i++)
            {
                if (!char.IsAsciiDigit(value[i]))
                    return false;
            }

            return true;
        }

        [Benchmark]
        public bool LinqCharIsAsciiDigit()
        {
            return value.All(char.IsAsciiDigit);
        }
    }
}

Full results. Click to expand.

BenchmarkDotNet v0.15.0, Windows 10 (10.0.19045.5917/22H2/2022Update)
AMD Ryzen 7 7840H with Radeon 780M Graphics 3.80GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 9.0.204
  [Host]             : .NET 9.0.5 (9.0.525.21509), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  .NET 6.0           : .NET 6.0.36 (6.0.3624.51421), X64 RyuJIT AVX2
  .NET 9.0           : .NET 9.0.5 (9.0.525.21509), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  .NET Core 3.1      : .NET Core 3.1.32 (CoreCLR 4.700.22.55902, CoreFX 4.700.22.56512), X64 RyuJIT AVX2
  .NET Framework 4.8 : .NET Framework 4.8.1 (4.8.9310.0), X64 RyuJIT VectorSize=256

Method	Runtime	Mean	Median	Allocated
Regex	.NET Framework 4.8	165.4417 ns	166.2537 ns	-
CompiledRegex	.NET Framework 4.8	115.9377 ns	115.9720 ns	-
GeneratedRegex	.NET Framework 4.8	N/A	N/A	-
LinqCharIsDigit	.NET Framework 4.8	92.1679 ns	92.2549 ns	96 B
ForCompare	.NET Framework 4.8	4.8703 ns	4.8602 ns	-
ForIsDigit	.NET Framework 4.8	8.3920 ns	8.3952 ns	-
ForIsAsciiDigit	.NET Framework 4.8	N/A	N/A	-
LinqCharIsAsciiDigit	.NET Framework 4.8	N/A	N/A	-
Regex	.NET Core 3.1	118.1540 ns	118.1887 ns	-
CompiledRegex	.NET Core 3.1	89.7392 ns	89.6514 ns	-
GeneratedRegex	.NET Core 3.1	N/A	N/A	-
LinqCharIsDigit	.NET Core 3.1	72.0987 ns	72.6419 ns	96 B
ForCompare	.NET Core 3.1	5.3070 ns	5.3077 ns	-
ForIsDigit	.NET Core 3.1	9.0998 ns	9.1106 ns	-
ForIsAsciiDigit	.NET Core 3.1	N/A	N/A	-
LinqCharIsAsciiDigit	.NET Core 3.1	N/A	N/A	-
Regex	.NET 6.0	57.8247 ns	57.8031 ns	-
CompiledRegex	.NET 6.0	21.2952 ns	21.2616 ns	-
GeneratedRegex	.NET 6.0	N/A	N/A	-
LinqCharIsDigit	.NET 6.0	74.2609 ns	74.4256 ns	96 B
ForCompare	.NET 6.0	5.6198 ns	5.5922 ns	-
ForIsDigit	.NET 6.0	10.3160 ns	10.1789 ns	-
ForIsAsciiDigit	.NET 6.0	N/A	N/A	-
LinqCharIsAsciiDigit	.NET 6.0	N/A	N/A	-
Regex	.NET 9.0	47.2579 ns	47.3506 ns	-
CompiledRegex	.NET 9.0	24.2419 ns	24.2547 ns	-
GeneratedRegex	.NET 9.0	17.2548 ns	17.2603 ns	-
LinqCharIsDigit	.NET 9.0	31.0294 ns	31.0501 ns	32 B
ForCompare	.NET 9.0	4.8587 ns	4.8656 ns	-
ForIsDigit	.NET 9.0	7.1207 ns	7.7792 ns	-
ForIsAsciiDigit	.NET 9.0	4.7515 ns	4.4976 ns	-
LinqCharIsAsciiDigit	.NET 9.0	32.6861 ns	32.5483 ns	32 B

The N/A mark is given to methods that do not exist in the current version of the framework.

Строка из чисел

Сергей Рогатнев — Sat, 07 Jun 2025 00:00:00 GMT

Популярная задача — определить, состоит ли строка только из числовых символов. Например, нужно проверить, что пользователь правильно ввел номер телефона, индекс или ИНН организации. Сделать это можно несколькими способами, которые отличаются своей эффективностью. Давайте рассмотрим самые популярные из них.

Regex

Наверное, это наиболее часто встречающийся способ. И действительно, что может быть проще использования регулярного выражения вида ^[0-9]*$ (или ^\d*$)?

Ниже представлена наивная реализация проверки с помощью регулярного выражения:

Regex regex = new Regex("^[0-9]*$");
var value = "123456789000";
var isValid = regex.IsMatch(value);

Возможно, вы уже видите здесь проблему. Такая реализация годится только для одноразового запуска. В промышленном коде, где вы проверяете сотни тысяч строк, такое решение будет не эффективным. .NET предоставляет возможность скомпилировать регулярное выражение во время выполнения при вызове конструктора, для это нужно использовать опцию RegexOptions.Compiled:

Regex regex = new Regex("^[0-9]*$", RegexOptions.Compiled);
var value = "123456789000";
var isValid = regex.IsMatch(value);

При вызове конструктора с этой опцией будет сгенерирован IL-код, который будет вызываться через DynamicMethod внутри Regex.IsMatch, что будет быстрее, чем обычная обработка регулярного выражения. Минусом же будет более долгое создание объекта Regex за счет затрат времени на компиляцию в рантайме, но это быстро окупается при многократном использовании.

Давайте сравним производительность двух вариантов.

Код бенчмарка. Нажмите, чтобы развернуть.

[MemoryDiagnoser]
[SimpleJob(RuntimeMoniker.Net90)]
[SimpleJob(RuntimeMoniker.Net60)]
[SimpleJob(RuntimeMoniker.NetCoreApp31)]
[SimpleJob(RuntimeMoniker.Net48)]
[HideColumns("Job", "Error", "StdDev", "Gen0")]
public partial class DigitsBenchmarks
{
    private static string value = "123456789000";

    private static readonly Regex regex = new Regex("^[0-9]*$");
    private static readonly Regex compiledRegex = new Regex("^[0-9]*$", RegexOptions.Compiled);

    [Benchmark]
    public bool Regex()
    {
        return regex.IsMatch(value);
    }
    
    [Benchmark]
    public bool CompiledRegex()
    {
        return compiledRegex.IsMatch(value);
    }
}

Результаты:

Method	Runtime	Mean	Median	Allocated
Regex	.NET Framework 4.8	165.4417 ns	166.2537 ns	-
CompiledRegex	.NET Framework 4.8	115.9377 ns	115.9720 ns	-
Regex	.NET Core 3.1	118.1540 ns	118.1887 ns	-
CompiledRegex	.NET Core 3.1	89.7392 ns	89.6514 ns	-
Regex	.NET 6.0	57.8247 ns	57.8031 ns	-
CompiledRegex	.NET 6.0	21.2952 ns	21.2616 ns	-
Regex	.NET 9.0	47.2579 ns	47.3506 ns	-
CompiledRegex	.NET 9.0	24.2419 ns	24.2547 ns	-

Преимущество использования скомпилированных выражений довольно наглядно. Так же с каждой новой версией .NET виден вклад разработчиков в производительность. Это еще один аргумент в пользу обновления на современные версии фреймворка.

Regex source generators

Повторюсь, что компиляция регулярных выражений имеет один недостаток — создание объекта Regex в рантайме будет занимать какое-то время. Можно ли от этого избавиться? Начиная с .NET 7 такая возможность появляется благодаря генераторам кода. Строго говоря, они появились в .NET 5, но решение для регулярных выражений было реализовано только в седьмой версии. Генераторы кода позволяют создавать C#-код на этапе компиляции. А значит его можно просматривать и дебажить так, словно это ваш собственный код. И регулярные выражения можно превратить в C#-код на этапе компиляции! В .NET для этого реализован специальный атрибут GeneratedRegex:

namespace DigitBenchmark
{
    public partial class DigitsBenchmarks
    {
        private static readonly Regex generatedRegex = GenerateRegex();
        
        [GeneratedRegex("^[0-9]*$")]
        private static partial Regex GenerateRegex();
    }
}

Давайте разберемся, что здесь происходит. Во-первых, нам нужно пометить наш класс DigitsBenchmarks как partial, т.к. часть сгенерированного кода для этого класса будет находиться в другом файле. Дальше нам нужно создать partial-метод, который будет возвращать объект типа Regex и пометить его атрибутом GeneratedRegex с указанием шаблона регулярного выражения. Опцию RegexOptions.Compiled указывать не нужно, она будет проигнорирована. Далее поймете почему.

Реализация метода GenerateRegex будет находиться в другом файле. Его можно найти в проекте и посмотреть исходный код:

namespace DigitBenchmark
{
    partial class DigitsBenchmarks
    {
        /// <remarks>
        /// Pattern:<br/>
        /// <code>^[0-9]*$</code><br/>
        /// Explanation:<br/>
        /// <code>
        /// ○ Match if at the beginning of the string.<br/>
        /// ○ Match a character in the set [0-9] atomically any number of times.<br/>
        /// ○ Match if at the end of the string or if before an ending newline.<br/>
        /// </code>
        /// </remarks>
        [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Text.RegularExpressions.Generator", "8.0.12.21506")]
        private static partial global::System.Text.RegularExpressions.Regex GenerateRegex() => global::System.Text.RegularExpressions.Generated.GenerateRegex_0.Instance;
    }
}

Как видите, автоматически был создан файл с тем же классом и содержащий реализацию нашего метода по генерации регулярного выражения. А дальше мы можем пользоваться этим объектом Regex как обычно. Так как это настоящий C#-код, то генерировать в рантайме ничего не нужно, поэтому и указывать опцию RegexOptions.Compiled нет смысла.

Какое преимущество мы от этого получим? В моих бенчмарках нет версий .NET 7 и 8, сравним производительность по последней на данный момент:

Method	Runtime	Mean	Median	Allocated
Regex	.NET 9.0	47.2579 ns	47.3506 ns	-
CompiledRegex	.NET 9.0	24.2419 ns	24.2547 ns	-
GeneratedRegex	.NET 9.0	17.2548 ns	17.2603 ns	-

Видим, что время сократилось почти на 30%! Компилятор имеет намного больше возможностей для оптимизации исходного кода на этапе компиляции, чем в рантайме.

char.IsDigit

Еще один популярный способ — использование статического метода char.IsDigit в сочетании с LINQ-методом All:

var value = "123456789000";
var isValid = value.All(char.IsDigit);

Давайте проверим, насколько хорош этот метод с точки зрения производительности.

Код бенчмарка. Нажмите, чтобы развернуть.

[MemoryDiagnoser]
[SimpleJob(RuntimeMoniker.Net90)]
[SimpleJob(RuntimeMoniker.Net60)]
[SimpleJob(RuntimeMoniker.NetCoreApp31)]
[SimpleJob(RuntimeMoniker.Net48)]
[HideColumns("Job", "Error", "StdDev", "Gen0")]
public partial class DigitsBenchmarks
{
    [Benchmark]
    public bool LinqCharIsDigit()
    {
        return value.All(char.IsDigit);
    }
}

Результаты:

Method	Runtime	Mean	Median	Allocated
LinqCharIsDigit	.NET Framework 4.8	92.1679 ns	92.2549 ns	96 B
LinqCharIsDigit	.NET Core 3.1	72.0987 ns	72.6419 ns	96 B
LinqCharIsDigit	.NET 6.0	74.2609 ns	74.4256 ns	96 B
LinqCharIsDigit	.NET 9.0	31.0294 ns	31.0501 ns	32 B

И сравним этот способ с предыдущими решениями.

Если в старых версиях фреймворка проверки через LINQ и метод IsDigit имеют преимущество над регулярными выражениями, то позже мы видим, что такая реализация начинает проигрывать.

Так же, обратите внимание, что каждый вызов такого метода приводит к выделению какого-то количества дополнительной памяти. Это значение складывается из 2-х составляющих:

Создание лямбда-выражения в параметре метода All(c => char.IsDigit(c)).
Создание итератора внутри метода All.

Примечательно, что в версии .NET 9 выделяется в 3 раза меньше памяти. До .NET 9 метод All был очень простым и состоял из цикла foreach с условием:

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
  //...
  foreach (TSource source1 in source)
  {
    if (!predicate(source1))
      return false;
  }
  return true;
}

Но в версии .NET 9 была добавлена важная оптимизация:

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
  //...
  ReadOnlySpan<TSource> span;
  if (source.TryGetSpan<TSource>(out span))
  {
    ReadOnlySpan<TSource> readOnlySpan = span;
    for (int index = 0; index < readOnlySpan.Length; ++index)
    {
      TSource source1 = readOnlySpan[index];
      if (!predicate(source1))
        return false;
    }
  }
  else
  {
    foreach (TSource source2 in source)
    {
      if (!predicate(source2))
        return false;
    }
  }
  return true;
}

Вместо безусловного цикла foreach метод All пробует получить из источника ReadOnlySpan - безопасный для чтения непрерывный блок памяти. И дальше используется простой цикл for, который не приводит к созданию итератора. Тем самым уменьшая количество дополнительной памяти. Полностью избавиться от этого можно переписав метод All на обычный цикл:

public bool ForIsDigit()
{
    for (var i = 0; i < value.Length; i++)
    {
        if (!char.IsDigit(value[i]))
            return false;
    }

    return true;
}

Помимо отсутствия лишнего memory-traffic данное решение является очень быстрым.

Что такое число?

Казалось бы, мы нашли оптимальное решение для проверки строки на наличие только чисел. Но предлагаю вам попробовать угадать, что выведет следующий код:

Console.WriteLine(char.IsDigit('0'));
Console.WriteLine(char.IsDigit('a'));
Console.WriteLine(char.IsDigit('٨'));
Console.WriteLine(char.IsDigit('৯'));

Нажмите, чтобы узнать ответ.

Console.WriteLine(char.IsDigit('0')); //True
Console.WriteLine(char.IsDigit('a')); //False
Console.WriteLine(char.IsDigit('٨')); //True
Console.WriteLine(char.IsDigit('৯')); //True

Думаю, вы удивлены результатом. Но в этом нет ничего необычного, метод IsDigit считает числами не только привычные нам символы из множества 0-9, но и все остальные символы, которые в кодировке Unicode относятся к числам. А их на самом деле много. Это может быть проблемой, если вы опираетесь на такую проверку в своём бизнес-коде.

Думаю, это послужило причиной появления нового метода char.IsAsciiDigit начиная с .NET 7. Вот он уже действительно проверяет только символы из множества 0-9.

Его реализация очень похожа на ручную проверку каждого символа в цикле, давай сравним оба варианта:

[Benchmark]
public bool ForCompare()
{
    for (var i = 0; i < value.Length; i++)
    {
        if (value[i] < '0' || value[i] > '9')
            return false;
    }

    return true;
}

[Benchmark]
public bool ForIsAsciiDigit()
{
    for (var i = 0; i < value.Length; i++)
    {
        if (!char.IsAsciiDigit(value[i]))
            return false;
    }

    return true;
}

Method	Runtime	Mean	Median	Allocated
ForCompare	.NET 9.0	4.8587 ns	4.8656 ns	-
ForIsAsciiDigit	.NET 9.0	4.7515 ns	4.4976 ns	-

Оба метода показывают эквивалентные результаты.

Заключение

Мы рассмотрели несколько разных способов проверить строку, состоит ли она только из чисел или нет. И важно понимать особенности работы некоторых из них, так как помимо банальных проблем производительности можно получить ошибки в бизнес-логике, если недостаточно качественно проверять входные данные.

Рекомендации:

Если вы пишете свои приложения под .NET 7 или выше, то используйте сгенерированные регулярные выражения. В противном случае указывайте опцию RegexOptions.Compiled.
Если вы пишете свои приложения под .NET 7 используйте метод char.IsAsciiDigit для проверки символов. В противном случае лучше написать проверку самому.

Ссылки

Полный код бенчмарка. Нажмите, чтобы развернуть.

using System.Linq;
using System.Text.RegularExpressions;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Jobs;

namespace DigitBenchmark
{
    [MemoryDiagnoser]
    [SimpleJob(RuntimeMoniker.Net90)]
    [SimpleJob(RuntimeMoniker.Net60)]
    [SimpleJob(RuntimeMoniker.NetCoreApp31)]
    [SimpleJob(RuntimeMoniker.Net48)]
    [HideColumns("Job", "Error", "StdDev", "Gen0")]
    public partial class DigitsBenchmarks
    {
        private static string value = "123456789000";

        private static readonly Regex regex = new Regex("^[0-9]*$");
        private static readonly Regex compiledRegex = new Regex("^[0-9]*$", RegexOptions.Compiled);
        private static readonly Regex generatedRegex = GenerateRegex();

        [GeneratedRegex("^[0-9]*$")]
        private static partial Regex GenerateRegex();

        [Benchmark]
        public bool Regex()
        {
            return regex.IsMatch(value);
        }
        
        [Benchmark]
        public bool CompiledRegex()
        {
            return compiledRegex.IsMatch(value);
        }

        [Benchmark]
        public bool GeneratedRegex()
        {
            return generatedRegex.IsMatch(value);
        }

        [Benchmark]
        public bool LinqCharIsDigit()
        {
            return value.All(char.IsDigit);
        }

        [Benchmark]
        public bool ForCompare()
        {
            for (var i = 0; i < value.Length; i++)
            {
                if (value[i] < '0' || value[i] > '9')
                    return false;
            }

            return true;
        }

        [Benchmark]
        public bool ForIsDigit()
        {
            for (var i = 0; i < value.Length; i++)
            {
                if (!char.IsDigit(value[i]))
                    return false;
            }

            return true;
        }

        [Benchmark]
        public bool ForIsAsciiDigit()
        {
            for (var i = 0; i < value.Length; i++)
            {
                if (!char.IsAsciiDigit(value[i]))
                    return false;
            }

            return true;
        }

        [Benchmark]
        public bool LinqCharIsAsciiDigit()
        {
            return value.All(char.IsAsciiDigit);
        }
    }
}

Все результаты бенчмарков. Нажмите, чтобы развернуть.

BenchmarkDotNet v0.15.0, Windows 10 (10.0.19045.5917/22H2/2022Update)
AMD Ryzen 7 7840H with Radeon 780M Graphics 3.80GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 9.0.204
  [Host]             : .NET 9.0.5 (9.0.525.21509), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  .NET 6.0           : .NET 6.0.36 (6.0.3624.51421), X64 RyuJIT AVX2
  .NET 9.0           : .NET 9.0.5 (9.0.525.21509), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  .NET Core 3.1      : .NET Core 3.1.32 (CoreCLR 4.700.22.55902, CoreFX 4.700.22.56512), X64 RyuJIT AVX2
  .NET Framework 4.8 : .NET Framework 4.8.1 (4.8.9310.0), X64 RyuJIT VectorSize=256

| Method               | Runtime            |        Mean |      Median | Allocated |
|----------------------|--------------------|------------:|------------:|----------:|
| Regex                | .NET Framework 4.8 | 165.4417 ns | 166.2537 ns |         - |
| CompiledRegex        | .NET Framework 4.8 | 115.9377 ns | 115.9720 ns |         - |
| GeneratedRegex       | .NET Framework 4.8 |         N/A |         N/A |         - |
| LinqCharIsDigit      | .NET Framework 4.8 |  92.1679 ns |  92.2549 ns |      96 B |
| ForCompare           | .NET Framework 4.8 |   4.8703 ns |   4.8602 ns |         - |
| ForIsDigit           | .NET Framework 4.8 |   8.3920 ns |   8.3952 ns |         - |
| ForIsAsciiDigit      | .NET Framework 4.8 |         N/A |         N/A |         - |
| LinqCharIsAsciiDigit | .NET Framework 4.8 |         N/A |         N/A |         - |
| Regex                | .NET Core 3.1      | 118.1540 ns | 118.1887 ns |         - |
| CompiledRegex        | .NET Core 3.1      |  89.7392 ns |  89.6514 ns |         - |
| GeneratedRegex       | .NET Core 3.1      |         N/A |         N/A |         - |
| LinqCharIsDigit      | .NET Core 3.1      |  72.0987 ns |  72.6419 ns |      96 B |
| ForCompare           | .NET Core 3.1      |   5.3070 ns |   5.3077 ns |         - |
| ForIsDigit           | .NET Core 3.1      |   9.0998 ns |   9.1106 ns |         - |
| ForIsAsciiDigit      | .NET Core 3.1      |         N/A |         N/A |         - |
| LinqCharIsAsciiDigit | .NET Core 3.1      |         N/A |         N/A |         - |
| Regex                | .NET 6.0           |  57.8247 ns |  57.8031 ns |         - |
| CompiledRegex        | .NET 6.0           |  21.2952 ns |  21.2616 ns |         - |
| GeneratedRegex       | .NET 6.0           |         N/A |         N/A |         - |
| LinqCharIsDigit      | .NET 6.0           |  74.2609 ns |  74.4256 ns |      96 B |
| ForCompare           | .NET 6.0           |   5.6198 ns |   5.5922 ns |         - |
| ForIsDigit           | .NET 6.0           |  10.3160 ns |  10.1789 ns |         - |
| ForIsAsciiDigit      | .NET 6.0           |         N/A |         N/A |         - |
| LinqCharIsAsciiDigit | .NET 6.0           |         N/A |         N/A |         - |
| Regex                | .NET 9.0           |  47.2579 ns |  47.3506 ns |         - |
| CompiledRegex        | .NET 9.0           |  24.2419 ns |  24.2547 ns |         - |
| GeneratedRegex       | .NET 9.0           |  17.2548 ns |  17.2603 ns |         - |
| LinqCharIsDigit      | .NET 9.0           |  31.0294 ns |  31.0501 ns |      32 B |
| ForCompare           | .NET 9.0           |   4.8587 ns |   4.8656 ns |         - |
| ForIsDigit           | .NET 9.0           |   7.1207 ns |   7.7792 ns |         - |
| ForIsAsciiDigit      | .NET 9.0           |   4.7515 ns |   4.4976 ns |         - |
| LinqCharIsAsciiDigit | .NET 9.0           |  32.6861 ns |  32.5483 ns |      32 B |

Отметка N/A ставится для методов, которые не существуют в данной версии фреймворка.