.net, C# and programming (RU)

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

Сергей Рогатнев — 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, и теперь он может обнаруживать списки с инициализатором коллекции и без начальной емкости.

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

Ссылки

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

Сергей Рогатнев — 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 |

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

Заключение

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

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

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

Сергей Рогатнев — 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 ставится для методов, которые не существуют в данной версии фреймворка.

Any() vs Count: часть 2

Сергей Рогатнев — Tue, 06 May 2025 00:00:00 GMT

В первой части мы сравнивали методы Any() и Count для различных коллекций и предложили вариант оптимизаций. Прошло достаточно времени, чтобы провести повторное сравнение.

Array

Начнем с самого простого типа для коллекции - массива. Проверим, есть ли какая-то разница между вызовами array.Any() и array.Length != 0.

Здесь и далее будет использоваться эта конфигурация:

BenchmarkDotNet v0.14.0, Windows 10 (10.0.19045.5796/22H2/2022Update)
AMD Ryzen 7 7840H with Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores
.NET SDK 9.0.203
  [Host]             : .NET 9.0.4 (9.0.425.16305), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  .NET 5.0           : .NET 5.0.17 (5.0.1722.21314), X64 RyuJIT AVX2
  .NET 6.0           : .NET 6.0.36 (6.0.3624.51421), X64 RyuJIT AVX2
  .NET 8.0           : .NET 8.0.15 (8.0.1525.16413), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  .NET 9.0           : .NET 9.0.4 (9.0.425.16305), 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

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

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

namespace AnyVsCount
{
    [MemoryDiagnoser]
    [SimpleJob(RuntimeMoniker.Net90)]
    [SimpleJob(RuntimeMoniker.Net80)]
    [SimpleJob(RuntimeMoniker.Net60)]
    [SimpleJob(RuntimeMoniker.Net50)]
    [SimpleJob(RuntimeMoniker.NetCoreApp31)]
    [SimpleJob(RuntimeMoniker.Net48)]
    [HideColumns("Job", "Error", "StdDev", "Gen0")]
    public class ArrayBenchmark
    {
        [Params(10, 10000)]
        public int N;

        private int[] array;

        [GlobalSetup]
        public void SetUp()
        {
            array = new int[N];
        }

        [Benchmark]
        public bool ArrayAny()
        {
            return array.Any();
        }

        [Benchmark]
        public bool ArrayCount()
        {
            return array.Length != 0;
        }
    }
}

Результаты

Method	Runtime	N	Mean	Median	Allocated
ArrayAny	.NET Framework 4.8	10	8.7962 ns	8.8213 ns	32 B
ArrayCount	.NET Framework 4.8	10	0.0073 ns	0.0028 ns	-
ArrayAny	.NET Core 3.1	10	8.0450 ns	8.0462 ns	32 B
ArrayCount	.NET Core 3.1	10	0.0433 ns	0.0399 ns	-
ArrayAny	.NET 5.0	10	6.2080 ns	6.1852 ns	-
ArrayCount	.NET 5.0	10	0.0030 ns	0.0000 ns	-
ArrayAny	.NET 6.0	10	6.0673 ns	6.0671 ns	-
ArrayCount	.NET 6.0	10	0.0135 ns	0.0135 ns	-
ArrayAny	.NET 8.0	10	5.0980 ns	5.2591 ns	-
ArrayCount	.NET 8.0	10	0.0000 ns	0.0000 ns	-
ArrayAny	.NET 9.0	10	2.1643 ns	2.1216 ns	-
ArrayCount	.NET 9.0	10	0.0030 ns	0.0034 ns	-
ArrayAny	.NET Framework 4.8	10000	9.0093 ns	9.0043 ns	32 B
ArrayCount	.NET Framework 4.8	10000	0.0123 ns	0.0137 ns	-
ArrayAny	.NET Core 3.1	10000	7.9624 ns	7.7794 ns	32 B
ArrayCount	.NET Core 3.1	10000	0.0311 ns	0.0295 ns	-
ArrayAny	.NET 5.0	10000	4.8357 ns	4.8352 ns	-
ArrayCount	.NET 5.0	10000	0.0008 ns	0.0007 ns	-
ArrayAny	.NET 6.0	10000	6.0913 ns	6.0747 ns	-
ArrayCount	.NET 6.0	10000	0.0147 ns	0.0153 ns	-
ArrayAny	.NET 8.0	10000	4.7691 ns	4.7521 ns	-
ArrayCount	.NET 8.0	10000	0.0110 ns	0.0078 ns	-
ArrayAny	.NET 9.0	10000	2.2933 ns	2.2906 ns	-
ArrayCount	.NET 9.0	10000	0.0121 ns	0.0109 ns	-

Значения близкие к нулю (например, 0.0000 ns) следует считать пренебрежимо малыми — они находятся в пределах погрешности измерений.

Легенда ко всем таблицам:

  N         : Value of the 'N' parameter
  Mean      : Arithmetic mean of all measurements
  Median    : Value separating the higher half of all measurements (50th percentile)
  Allocated : Allocated memory per single operation (managed only, inclusive, 1KB = 1024B)
  1 ns      : 1 Nanosecond (0.000000001 sec)

Можно заметить, что для массива результаты практически не зависят от размера, поэтому дальше будет рассматривать только результаты для N = 10000. Дальше мы видим, что прямой вызов свойства Length у массива минимум на 2 порядка быстрее вызова метода Any() и кажется, что нет никакого смысла его использовать. Но зачастую мы работаем не с коллекциями напрямую, а с обобщенным кодом:

public bool IsEmpty<T>(IEnumerable<T> collection)
{
    return !collection.Any();
}

Поэтому продолжим наше исследование и внимательнее посмотрим, почему получается такая разница в методе Any() в разных версиях фреймворка. Видно, что от .NET 4.8 до .NET 9.0 время выполнения метода Any() уменьшилось в 4 раза:

Разница между последней версией классического фреймворка и .NET Core незначительная. Давайте посмотрим на реализацию метода Any() внутри .NET 4.8 и .NET Core 3.1 (они совпадают):

public static bool Any<TSource>(this IEnumerable<TSource> source)
{
    if (source == null)
    {
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.source);
    }

    using (IEnumerator<TSource> e = source.GetEnumerator())
    {
        return e.MoveNext();
    }
}

Как видим, чтобы определить, есть ли в последовательности хотя бы один элемент, создаётся итератор по этой последовательности и вызывается метод MoveNext(). На это же нам намекали 32 байта выделяемой памяти в бенчмарке - это как раз затраты на создание итератора. Что же изменилось в .NET 5? Давайте опять посмотрим на код:

public static bool Any<TSource>(this IEnumerable<TSource> source)
{
    if (source == null)
    {
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.source);
    }

    if (source is ICollection<TSource> collectionoft)
    {
        return collectionoft.Count != 0;
    }
    else if (source is IIListProvider<TSource> listProv)
    {
        int count = listProv.GetCount(onlyIfCheap: true);
        if (count >= 0)
        {
            return count != 0;
        }
    }
    else if (source is ICollection collection)
    {
        return collection.Count != 0;
    }

    using (IEnumerator<TSource> e = source.GetEnumerator())
    {
        return e.MoveNext();
    }
}

Решение подозрительно похоже на то, что мы использовали в первой части. Вначале проверяется, реализует ли перечисление интерфейс ICollection<T>, у которого есть свойство Count. А дальше мы видим использование нового интерфейса IIListProvider<TSource> (внутренний интерфейс .NET, оптимизирующий операции LINQ за счёт избегания перечисления элементов):

internal interface IIListProvider<TElement> : IEnumerable<TElement>
{
    TElement[] ToArray();

    List<TElement> ToList();

    int GetCount(bool onlyIfCheap);
}

Этот интерфейс - часть масштабной переработки LINQ, которая позволила добиться значительной оптимизации заметной даже на простом методе Any(). Любопытно, что в .NET 6 производительность несколько ухудшилась, хотя реализация метода Any() не изменилась.

В восьмой версии .NET код, который вычисляет размер перечисления (не выполняя то самое перечисление) вынесли в отдельный метод TryGetNonEnumeratedCount(). Этот метод работает за константное время, но не всегда может вернуть значение.

В девятой версии .NET концепция использования IIListProvider<TSource> получила развитие и LINQ-методы были переработаны с использованием нового класса Iterator<TSource>, что позволило еще улучшить производительность.

Как видим, напрашивающееся решение с проверкой типа перечисления и свойства Count было реализовано в новых версиях .NET. Будет ли это эффективно для всех коллекций?

ConcurrentDictionary

Давайте рассмотрим самую распространенную потокобезопасную коллекцию - ConcurrentDictionary<TKey, TValue>. Кажется, что с новой реализацией могут быть проблемы.

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

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

namespace AnyVsCount
{
    [MemoryDiagnoser]
    [SimpleJob(RuntimeMoniker.Net90)]
    [SimpleJob(RuntimeMoniker.Net80)]
    [SimpleJob(RuntimeMoniker.Net60)]
    [SimpleJob(RuntimeMoniker.Net50)]
    [SimpleJob(RuntimeMoniker.NetCoreApp31)]
    [SimpleJob(RuntimeMoniker.Net48)]
    [HideColumns("Job", "Error", "StdDev", "Gen0")]
    public class ConcurrentDictionaryBenchmark
    {
        [Params(10, 10000)]
        public int N;

        private ConcurrentDictionary<int, string> dictionary;

        [GlobalSetup]
        public void SetUp()
        {
            dictionary = new ConcurrentDictionary<int, string>();

            for (int i = 0; i < N; i++)
            {
                dictionary[i] = i.ToString();
            }
        }

        [Benchmark]
        public bool DictionaryAny()
        {
            return dictionary.Any();
        }

        [Benchmark]
        public bool DictionaryCount()
        {
            return dictionary.Count != 0;
        }
    }
}

Результаты

Method	Runtime	N	Mean	Median	Allocated
DictionaryAny	.NET Framework 4.8	10	18.48 ns	18.47 ns	64 B
DictionaryCount	.NET Framework 4.8	10	110.77 ns	110.75 ns	-
DictionaryAny	.NET Core 3.1	10	18.21 ns	18.17 ns	64 B
DictionaryCount	.NET Core 3.1	10	108.27 ns	110.12 ns	-
DictionaryAny	.NET 5.0	10	92.98 ns	92.81 ns	-
DictionaryCount	.NET 5.0	10	97.02 ns	96.42 ns	-
DictionaryAny	.NET 6.0	10	87.96 ns	87.79 ns	-
DictionaryCount	.NET 6.0	10	88.35 ns	88.40 ns	-
DictionaryAny	.NET 8.0	10	76.10 ns	76.08 ns	-
DictionaryCount	.NET 8.0	10	72.26 ns	72.27 ns	-
DictionaryAny	.NET 9.0	10	83.02 ns	83.52 ns	-
DictionaryCount	.NET 9.0	10	80.43 ns	79.34 ns	-
DictionaryAny	.NET Framework 4.8	10000	18.87 ns	18.71 ns	64 B
DictionaryCount	.NET Framework 4.8	10000	6,870.38 ns	6,859.65 ns	-
DictionaryAny	.NET Core 3.1	10000	18.04 ns	18.06 ns	64 B
DictionaryCount	.NET Core 3.1	10000	7,000.55 ns	7,000.95 ns	-
DictionaryAny	.NET 5.0	10000	5,877.30 ns	5,877.50 ns	-
DictionaryCount	.NET 5.0	10000	5,962.47 ns	5,958.17 ns	-
DictionaryAny	.NET 6.0	10000	5,993.15 ns	5,994.17 ns	-
DictionaryCount	.NET 6.0	10000	6,030.51 ns	6,029.08 ns	-
DictionaryAny	.NET 8.0	10000	5,082.70 ns	5,082.69 ns	-
DictionaryCount	.NET 8.0	10000	5,370.34 ns	5,368.76 ns	-
DictionaryAny	.NET 9.0	10000	5,917.83 ns	5,917.32 ns	-
DictionaryCount	.NET 9.0	10000	5,847.50 ns	5,848.04 ns	-

Уже видны некоторые особенности:

Время выполнения зависит от размера коллекции.
В старых версиях фреймворка метод Any() был намного быстрее.
В новых версиях фреймворка метод Any() сровнялся по производительности с Count:

Давайте посмотрим реализацию свойства Count:

public int Count
{
    get
    {
        int locksAcquired = 0;
        try
        {
            AcquireAllLocks(ref locksAcquired);

            return GetCountNoLocks();
        }
        finally
        {
            ReleaseLocks(locksAcquired);
        }
    }
}

private void AcquireAllLocks(ref int locksAcquired)
{
    //...

    // First, acquire lock 0, then acquire the rest. _tables won't change after acquiring lock 0.
    AcquireFirstLock(ref locksAcquired);
    AcquirePostFirstLock(_tables, ref locksAcquired);
    Debug.Assert(locksAcquired == _tables._locks.Length);
}

Подсчет всех элементов требует получения блокировок на специальный внутренний массив _tables._locks. Каждый элемент этого массива блокирует часть словаря. Таким образом, начиная с .NET 5, метод Any() для ConcurrentDictionary использует свойство Count через ICollection<T>, что приводит к таким же блокировкам, как и при прямом вызове Count.

Any() и IsEmpty

Давайте восстановим реализацию Any() с итератором и проверим производительность этого метода:

[Benchmark]
public bool DictionaryEnumerator()
{
    using (var enumerator = dictionary.GetEnumerator())
    {
        return enumerator.MoveNext();
    }
}

Method	Runtime	N	Mean	Median	Allocated
DictionaryEnumerator	.NET Framework 4.8	10	15.51 ns	15.52 ns	64 B
DictionaryEnumerator	.NET Core 3.1	10	14.60 ns	14.60 ns	64 B
DictionaryEnumerator	.NET 5.0	10	15.16 ns	15.14 ns	64 B
DictionaryEnumerator	.NET 6.0	10	18.60 ns	18.67 ns	64 B
DictionaryEnumerator	.NET 8.0	10	12.97 ns	12.96 ns	64 B
DictionaryEnumerator	.NET 9.0	10	12.80 ns	12.81 ns	64 B
DictionaryEnumerator	.NET Framework 4.8	10000	15.41 ns	15.38 ns	64 B
DictionaryEnumerator	.NET Core 3.1	10000	15.03 ns	14.96 ns	64 B
DictionaryEnumerator	.NET 5.0	10000	15.90 ns	15.92 ns	64 B
DictionaryEnumerator	.NET 6.0	10000	18.50 ns	18.50 ns	64 B
DictionaryEnumerator	.NET 8.0	10000	13.38 ns	12.92 ns	64 B
DictionaryEnumerator	.NET 9.0	10000	12.97 ns	12.53 ns	64 B

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

Но можно воспользоваться специализированным свойством коллекции - IsEmpty:

[Benchmark]
public bool DictionaryIsEmpty()
{
    return !dictionary.IsEmpty;
}

Method	Runtime	N	Mean	Median	Allocated
DictionaryIsEmpty	.NET Framework 4.8	10	99.023 ns	98.709 ns	-
DictionaryIsEmpty	.NET Core 3.1	10	2.313 ns	2.313 ns	-
DictionaryIsEmpty	.NET 5.0	10	2.545 ns	2.545 ns	-
DictionaryIsEmpty	.NET 6.0	10	2.247 ns	2.283 ns	-
DictionaryIsEmpty	.NET 8.0	10	2.567 ns	2.568 ns	-
DictionaryIsEmpty	.NET 9.0	10	10.917 ns	10.902 ns	-
DictionaryIsEmpty	.NET Framework 4.8	10000	6,027.991 ns	6,026.648 ns	-
DictionaryIsEmpty	.NET Core 3.1	10000	2.320 ns	2.315 ns	-
DictionaryIsEmpty	.NET 5.0	10000	2.513 ns	2.512 ns	-
DictionaryIsEmpty	.NET 6.0	10000	2.756 ns	2.759 ns	-
DictionaryIsEmpty	.NET 8.0	10000	2.673 ns	2.673 ns	-
DictionaryIsEmpty	.NET 9.0	10000	3.801 ns	3.804 ns	-

Видим, что уже начиная с .NET Core 3.1 реализация этого свойства не зависит от размера коллекции и в случае не пустых коллекций вызов этого свойства не является блокирующим. Для .NET 4.8 мы получили результаты аналогичные вызову свойства Count - так же используется блокировка на всю коллекцию. Для .NET 9 результаты получились несколько хуже, но у меня нет быстрого ответа, почему так произошло.

Заключение

Реализация метода Any() сегодня достаточно оптимизирована, чтобы его использовать в обобщенном коде, но еще есть задел на его использование в потокобезопасных коллекциях.

nvarchar(max) vs nvarchar(N)

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

MS SQL Server предоставляет нам на выбор несколько типов данных для хранения строк. Самый популярный - nvarchar(N) (где 1 ≤ N ≤ 4000) или nvarchar(max), который позволяет хранить строковые данные в кодировке Юникод. При этом, часто прикладные разработчики переносят опыт использования типа string из языка приложения (C# или Java, например) в базы данных и не задумываясь выбирают тип nvarchar(max), позволяющий хранить строки размером до 2ГБ. Но базы данных хранят и работают с данными совершенно другим способом. В этой статье я расскажу и покажу на практике, к чему может приводить неоправданное использование типа nvarchar(max).

Подготовка

Давайте создадим 3 таблицы, хранящие текстовые данные:

CREATE TABLE [dbo].[nv100]
(
	[Id] [int] NOT NULL,
	[CreateDate] [datetime] NOT NULL,
	[Comment] [nvarchar](100) NOT NULL,
	CONSTRAINT [PK_nv100_Id] PRIMARY KEY CLUSTERED ([Id] ASC)
)

CREATE TABLE [dbo].[nv1000]
(
	[Id] [int] NOT NULL,
	[CreateDate] [datetime] NOT NULL,
	[Comment] [nvarchar](1000) NOT NULL,
	CONSTRAINT [PK_nv1000_Id] PRIMARY KEY CLUSTERED ([Id] ASC)
)

CREATE TABLE [dbo].[nvmax]
(
	[Id] [int] NOT NULL,
	[CreateDate] [datetime] NOT NULL,
	[Comment] [nvarchar](max) NOT NULL,
	CONSTRAINT [PK_nvmax_Id] PRIMARY KEY CLUSTERED ([Id] ASC)
)

Таблицы отличаются типом колонки Comment. Заполним эти таблицы 200 000 строками подобного вида:

Id          CreateDate              Comment
----------- ----------------------- ----------
1           2025-01-01 00:00:01.000 1
2           2025-01-01 00:00:02.000 2
3           2025-01-01 00:00:03.000 3
4           2025-01-01 00:00:04.000 4
5           2025-01-01 00:00:05.000 5
6           2025-01-01 00:00:06.000 6
7           2025-01-01 00:00:07.000 7
8           2025-01-01 00:00:08.000 8
9           2025-01-01 00:00:09.000 9
10          2025-01-01 00:00:10.000 10

Тестируем выборки

Просто выберем все данные из таблиц и посмотрим на план выполнения:

select *
from nv100

select *
from nv1000

select *
from nvmax

На первый взгляд мы получаем 3 одинаковых плана:

Давайте посмотрим на единственную стрелочку в плане первого запроса:

Мы видим, что SQL Server правильно определил количество строк, которые необходимо вернуть - 200 000. Это предсказуемо, т.к. мы выбираем все данные из таблицы. Более интересный показатель Estimated Row Size - предполагаемый размер одной строки в байтах. Из чего он складывается? Это метаданные, которые есть в каждой строке и непосредственно сами данные. В нашем случае 4 байта отводится под идентификатор типа int, 8 байт для поля типа datetime и из документации мы знаем, что тип nvarchar(n) занимает 2*n байт. Для колонки с типом nvarchar(100) будет 200 байт. 4 + 8 + 200 = 212 байт. Почему же SQL Server оценивает размер в 123 байта?

При составлении плана запроса сервер делает оценку по полю nvarchar(n) как половину от максимально возможного количества байт. Т.е. 100 байт для первой таблицы. Таким образом, предполагаемый объем занимаемых данных в одной строке - 4 + 8 + 100 = 112 байт. Еще несколько байт занимают метаданные. Давайте посмотрим на план запроса для второй таблицы:

Видим, что Estimated Row Size вырос до 1023 байт, из которых на данные отводится теперь 4 + 8 + 1000 = 1012 байт, остальное - опять метаданные. А что же будет для типа nvarchar(max)? Данный тип данных позволяет хранить до 2ГБ. Неужели, каждая строка будет получать оценку в 1ГБ данных? На самом деле нет, SQL Server оценивает такие данные в 4000 байт:

Если мы исключим колонку Comment из выборки, то SQL Server будет делать точные оценки:

select Id, CreateDate
from nvmax

Сортировка

Как мы знаем, перед выполнением запроса SQL Server пытается оставить оптимальный план - то, как именно получить данные, какие алгоритмы использовать. На составление плана влияет множество параметров: размеры таблиц, наличие индексов, типы данных и многое другое... Один из таких влияющих параметров - Estimated Row Size. Опираясь на него SQL Server определяет, сколько оперативной памяти нужно выделить под выполнение определенного запроса и нужно ли использовать TempDB (например, для сортировки больших данных).

Давайте проверим это на примере и отсортируем нашу выборку по комментарию:

select *
from nv100
order by Comment desc

select *
from nv1000
order by Comment desc

select *
from nvmax
order by Comment desc

И посмотрим на план выполнения:

Получаются очень похожие планы, но обратите внимание на восклицательный знак возле оператора SELECT во втором запросе - там явно есть какая-то проблема:

Мы видим предупреждение типа Excessive Grant. Основываясь на оценках объема данных SQL Server запросил для выполнения запроса 295616 килобайт (~300 мегабайт), а фактически было использовано всего 14584 килобайт (~15 мегабайт), т.е. в 20 раз меньше.

Еще хуже ситуация с третьим запросом:

Запросив 1122496 килобайт (~1.1 гигабайт), было использовано всего 19960 килобайт (~20 мегабайт) - в 56 раз меньше. Фактически, мы заставили SQL Server выделить лишний гигабайт памяти, который никак не был использован. Как минимум, это не полезно, а в худшем случае - может отнять ресурсы у более полезного запроса.

Фильтрация

Давайте сделаем выборку с фильтрацией по полю Comment:

select *
from nv100
where Comment = N'12345'

select *
from nv1000
where Comment = N'12345'

select *
from nvmax
where Comment = N'12345'

И традиционно посмотрим на план выполнения:

Во всех случаях мы полностью сканируем кластерный индекс, но бросается в глаза, что в случае с таблицей nvmax появляется дополнительная операция Filter. Почему так? Причина в способе хранения данных. Данные типа nvarchar(max) могут храниться двумя разными способами:

IN_ROW_DATA - если данные меньше или равны 8000 байт, то они хранятся непосредственно в строке таблицы.
LOB_DATA - если данные превышают 8000 байт, то они хранятся в отдельных страницах внутри файлов базы данных. В строке остаётся только указатель на эти данные.

В нашей колонке Comment данные значительно меньше 8000 байт, но SQL Server мог по другим причинам разместить данные в LOB_DATA. Давайте проверим, где именно располагаются данные:

SELECT
	t.Name as TableName,
	a.type_desc as StorageType
FROM sys.tables t
JOIN sys.columns c ON t.object_id = c.object_id
JOIN sys.partitions p ON t.object_id = p.object_id
JOIN sys.allocation_units a ON p.partition_id = a.container_id
WHERE c.system_type_id = 231 -- nvarchar(max)
  AND a.type_desc IN ('IN_ROW_DATA', 'LOB_DATA')

Результат запроса:

TableName  StorageType
---------- -------------
nv100      IN_ROW_DATA
nv1000     IN_ROW_DATA
nvmax      IN_ROW_DATA
nvmax      LOB_DATA

Видим, что для таблиц nv100 и nv1000 данные хранятся только в режиме IN_ROW_DATA. Для таблицы nvmax используются оба варианта (IN_ROW_DATA, LOB_DATA). Возвращаясь к запросу с фильтрацией, такое расположение данных приводит к тому, что серверу предварительно требуется извлечь данные, а только потом применить фильтрацию. От этого в плане запроса мы видим дополнительную операцию Filter.

Индексы

Да, поиск по строке, не самый частый сценарий. А если это и требуется, то логично создать индекс. Но тут очевидное ограничение, на колонку с типом nvarchar(max) нельзя создать индекс. Более того, при попытке создать индекс на колонку с типом nvarchar(1000) мы получим предупреждение:

CREATE NONCLUSTERED INDEX [IX_nv1000_Comment] ON [dbo].[nv1000]
(
	[Comment] ASC
)

Warning! The maximum key length for a nonclustered index is 1700 bytes. The index 'IX_nv1000_Comment' has maximum length of 2000 bytes. For some combination of large values, the insert/update operation will fail.

Индекс будет работать только для определенных данных. При попытке вставить строку максимальной длины мы получим ошибку:

insert into nv1000
values(-1, GETUTCDATE(), REPLICATE(N'A',1000))

Msg 1946, Level 16, State 3, Line 1
Operation failed. The index entry of length 2000 bytes for the index 'IX_nv1000_Comment' exceeds the maximum length of 1700 bytes for nonclustered indexes.

Сравнение

	nvarchar(100)	nvarchar(1000)	nvarchar(max)
Хранение данных	IN_ROW_DATA	IN_ROW_DATA	IN_ROW_DATA/LOB_DATA
Оценка размера строки	100 байт	1000 байт	4000 байт
Индекс	Да	Да, с ограничениями	Нет

Выводы

Число n в определении типа nvarchar(n) - не просто ограничение максимальной длины строки. Это важная информация, которая помогает SQL Server'у выбирать наиболее оптимальный план запроса.
Использование nvarchar(max) должно быть оправдано и использоваться для действительно больших строк. Скорее всего, ваша бизнес-логика ограничивает максимальную длину строки в приложении. Если это пользовательский ввод или API - там наверняка будут ограничения. Перенесите эти ограничения на базу данных.
Оптимальным размером для типа nvarchar(n) будет удвоенная средняя длина хранящихся строк.

Ссылки

nchar и nvarchar (Transact-SQL)

LINQ: Any() vs Count

Сергей Рогатнев — Sun, 17 Jun 2018 00:00:00 GMT

Эта статья началась с обсуждения на Stack Overflow: Why LINQ method Any does not check Count?. Здесь мы сравним производительность методов Any и Count != 0.

UPD: Вышла вторая часть статьи: Any() vs Count: часть 2, где сравниваются реализации в новых версиях .NET. Эта статья только о .NET 4.7.1.

Сначала добавим наш собственный метод-расширения, который реализует нужную логику сравнения:

public static class EnumerableExtensions
{
    public static bool CustomAny<TSource>(this IEnumerable<TSource> source)
    {
        if (source == null)
        {
            throw new ArgumentNullException(nameof(source));
        }

        if (source is ICollection<TSource> collection)
        {
            return collection.Count != 0;
        }

        using (var enumerator = source.GetEnumerator())
        {
            if (enumerator.MoveNext())
                return true;
        }

        return false;
    }
}

Идея: для коллекций, реализующих ICollection<T>, использовать свойство Count, чтобы избежать создания энумератора. Но будет ли это быстрее стандартного Any()?

Используем BenchmarkDotNet для тестирования.

Проверим на следующих коллекциях:

List
Array
HashSet
Dictionary
Stack
Queue
SortedList
SortedSet

Каждая коллекция содержит 1000 элементов. Сравниваем Any() и CustomAny():

[CategoriesColumn]
[GroupBenchmarksBy(BenchmarkLogicalGroupRule.ByCategory)]
public class SimpleCollections
{
    [Params(1000)]
    public int _size;

    private List<int> _list;
    private int[] _array;
    private HashSet<int> _hashSet;
    private Dictionary<int, int> _dictionary;
    private Stack<int> _stack;
    private Queue<int> _queue;
    private SortedList<int, int> _sortedList;
    private SortedSet<int> _sortedSet;

    [GlobalSetup]
    public void SetUp()
    {
        _list = new List<int>();
        _array = new int[_size];
        _hashSet = new HashSet<int>();
        _dictionary = new Dictionary<int, int>();
        _stack = new Stack<int>();
        _queue = new Queue<int>();
        _sortedList = new SortedList<int, int>();
        _sortedSet = new SortedSet<int>();

        for (int i = 0; i < _size; i++)
        {
            _list.Add(i);
            _array[i] = i;
            _hashSet.Add(i);
            _dictionary[i] = i;
            _stack.Push(i);
            _queue.Enqueue(i);
            _sortedList.Add(i, i);
            _sortedSet.Add(i);
        }
    }
    
    [Benchmark(Baseline = true, Description = "Any"), BenchmarkCategory("List")]
    public bool ListAny()
    {
        return _list.Any();
    }

    [Benchmark(Description = "Custom"), BenchmarkCategory("List")]
    public bool ListCount()
    {
        return _list.CustomAny();
    }
    
    ///other collections
}

Первые результаты

BenchmarkDotNet=v0.10.14, OS=Windows 10.0.17134
Intel Core i7-2670QM CPU 2.20GHz (Sandy Bridge), 1 CPU, 8 logical and 4 physical cores
Frequency=2143565 Hz, Resolution=466.5126 ns, Timer=TSC
  [Host]     : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.3110.0
  DefaultJob : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.3110.0

Method	Categories	_size	Mean	Median	Scaled	ScaledSD
Any	List	1000	38.88 ns	38.32 ns	1.00	0.00
Custom	List	1000	16.49 ns	16.50 ns	0.43	0.02

Any	Array	1000	27.46 ns	27.39 ns	1.00	0.00
Custom	Array	1000	51.21 ns	50.60 ns	1.87	0.05

Any	HashSet	1000	39.87 ns	39.89 ns	1.00	0.00
Custom	HashSet	1000	15.06 ns	15.01 ns	0.38	0.00

Any	Dictionary	1000	51.14 ns	50.83 ns	1.00	0.00
Custom	Dictionary	1000	17.41 ns	17.36 ns	0.34	0.01

Any	Stack	1000	42.10 ns	42.29 ns	1.00	0.00
Custom	Stack	1000	49.41 ns	48.60 ns	1.17	0.06

Any	Queue	1000	44.68 ns	44.41 ns	1.00	0.00
Custom	Queue	1000	50.68 ns	50.66 ns	1.14	0.04

Any	SortedList	1000	42.89 ns	42.55 ns	1.00	0.00
Custom	SortedList	1000	17.48 ns	17.17 ns	0.41	0.02

Any	SortedSet	1000	220.19 ns	219.66 ns	1.00	0.00
Custom	SortedSet	1000	18.46 ns	18.34 ns	0.08	0.00

Здесь и далее испльзуется легенда:

  Categories : Collection type
  _size      : Number of elements in collection
  Mean       : Arithmetic mean of all measurements
  Error      : Half of 99.9% confidence interval
  StdDev     : Standard deviation of all measurements
  Median     : Value separating the higher half of all measurements (50th percentile)
  Scaled     : Mean(CurrentBenchmark) / Mean(BaselineBenchmark)
  ScaledSD   : Standard deviation of ratio of distribution of [CurrentBenchmark] and [BaselineBenchmark]
  1 ns       : 1 Nanosecond (0.000000001 sec)

Как мы видим, новый метод с проверкой Count быстрее или сравним по производительности со стандартным Any() за исключением нескольких коллекций.

Почему массив замедлился?

Хотя массивы реализуют ICollection<T>, проверка типа source is ICollection<T> в .NET работает медленнее для них. Решение — добавить отдельную проверку на массив:

public static class EnumerableExtensions
{
    public static bool CustomAny<TSource>(this IEnumerable<TSource> source)
    {
        // ... остальная логика ...

        if (source is TSource[] array)
        {
            return array.Length != 0;
        }

        // ... остальная логика ...
    }
}

После доработки результаты для массива улучшились:

Method	Categories	_size	Mean	Scaled	ScaledSD	ScaledSD
Any	Array	1000	27.11 ns	1.00	0.00	0.00
Custom	Array	1000	18.87 ns	0.70	0.02	0.05

Stack and Queue

Проблема: Stack<T> и Queue<T> не реализуют ICollection<T>:

public class Stack<T> : IEnumerable<T>, IEnumerable, ICollection, IReadOnlyCollection<T>

public class Queue<T> : IEnumerable<T>, IEnumerable, ICollection, IReadOnlyCollection<T>

Но имеют необобщенный ICollection. Добавим проверку:

public static class EnumerableExtensions
{
    public static bool CustomAny<TSource>(this IEnumerable<TSource> source)
    {
        // ... остальная логика ...

        if (source is ICollection baseCollection)
        {
            return baseCollection.Count != 0;
        }

        // ... остальная логика ...

        return false;
    }
}

Результаты после оптимизации:

Method	Categories	_size	Mean	Scaled	ScaledSD	ScaledSD
Any	Stack	1000	39.56 ns	1.00	0.00	0.00
Custom	Stack	1000	31.66 ns	0.80	0.01	0.06

Any	Queue	1000	42.90 ns	1.00	0.00	0.00
Custom	Queue	1000	31.69 ns	0.74	0.00	0.04

Загадка SortedSet

Почему Any() для SortedSet такой медленный? Всё дело в реализации его энумератора.

Метод GetEnumerator создаёт структуру типа Enumerator, которая принимает SortedSet<T> в качестве параметра конструктора:

internal Enumerator(SortedSet<T> set)
{
  this.tree = set;
  this.tree.VersionCheck();
  this.version = this.tree.version;
  this.stack = new Stack<SortedSet<T>.Node>(2 * SortedSet<T>.log2(set.Count + 1));
  this.current = (SortedSet<T>.Node) null;
  this.reverse = false;
  this.siInfo = (SerializationInfo) null;
  this.Intialize();
}

Взглянем на метод Intialize (с опечаткой в названии):

private void Intialize()
{
  this.current = (SortedSet<T>.Node) null;
  SortedSet<T>.Node node1 = this.tree.root;
  while (node1 != null)
  {
    SortedSet<T>.Node node2 = this.reverse ? node1.Right : node1.Left;
    SortedSet<T>.Node node3 = this.reverse ? node1.Left : node1.Right;
    if (this.tree.IsWithinRange(node1.Item))
    {
      this.stack.Push(node1);
      node1 = node2;
    }
    else
      node1 = node2 == null || !this.tree.IsWithinRange(node2.Item) ? node3 : node2;
  }
}

Класс SortedSet<T> построен на бинарном дереве, а метод Intialize обходит все узлы дерева и помещает элементы в стек. Таким образом, при создании энумератора для SortedSet, его внутренняя реализация фактически формирует новую коллекцию со всеми элементами. Чем больше элементов, тем больше времени тратится на это копирование:

Method	_size	Mean	Scaled
Any	1000	230.64 ns	1.00
Custom	1000	22.23 ns	0.10

Any	10000	288.27 ns	1.00
Custom	10000	21.72 ns	0.08

Any	100000	343.54 ns	1.00
Custom	100000	21.70 ns	0.06

Мы проверили наиболее популярные коллекции и можно сказать, что мы должны использовать свойство Count вместо вызова метода Enumerable.Any(). Но всегда ли безопасно использовать Count? Есть ли коллекции, где вычисление свойства Count занимает больше времени, чем создание энумератора? Вы будете удивлены.

Concurrent collections

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

ConcurrentBag
ConcurrentDictionary
ConcurrentQueue
ConcurrentStack

Давайте для теста заполним эти коллекции из разных потоков симулируя многопоточную работу:

[GlobalSetup]
public void SetUp()
{
    _bag = new ConcurrentBag<int>();
    _dictionary = new ConcurrentDictionary<int, int>();
    _queue = new ConcurrentQueue<int>();
    _stack = new ConcurrentStack<int>();

    var tasksCount = 10;
    var batch = _size / tasksCount;

    var tasks = new Task[tasksCount];

    for (int i = 0; i < tasksCount; i++)
    {
        var task = i;

        tasks[task] = Task.Run(() =>
        {
            var from = task * batch;
            var to = (task + 1) * batch;

            for (int j = from; j < to; j++)
            {
                _bag.Add(j);
                _dictionary[j] = j;
                _queue.Enqueue(j);
                _stack.Push(j);
            }
        });
    }

    Task.WaitAll(tasks);
}

Результаты

Method	Categories	_size	Mean	Scaled	ScaledSD
Any	ConcurrentBag	1000	7,065.75 ns	1.00	0.00
Custom	ConcurrentBag	1000	267.89 ns	0.04	0.00

Any	ConcurrentDictionary	1000	39.29 ns	1.00	0.00
Custom	ConcurrentDictionary	1000	6,319.42 ns	160.88	2.45

Any	ConcurrentStack	1000	28.08 ns	1.00	0.00
Custom	ConcurrentStack	1000	3,179.18 ns	113.23	0.93

Any	ConcurrentQueue	1000	72.12 ns	1.00	0.00
Custom	ConcurrentQueue	1000	48.28 ns	0.67	0.02

Получили неожиданные результаты. Где-то Any() очень медленный, а где-то наоборот.

ConcurrentBag

Метод GetEnumerator работает аналогично как и в SortedSet. Он блокирует исходную коллекцию и копирует все элементы в новый список:

private List<T> ToList()
{
  List<T> objList = new List<T>();
  for (ConcurrentBag<T>.ThreadLocalList threadLocalList = this.m_headList; threadLocalList != null; threadLocalList = threadLocalList.m_nextList)
  {
    for (ConcurrentBag<T>.Node node = threadLocalList.m_head; node != null; node = node.m_next)
      objList.Add(node.m_value);
  }
  return objList;
}

Свойство Count блокирует коллекцию и суммирует внутренние счетчики количества элементов:

private int GetCountInternal()
{
  int num = 0;
  for (ConcurrentBag<T>.ThreadLocalList threadLocalList = this.m_headList; threadLocalList != null; threadLocalList = threadLocalList.m_nextList)
    checked { num += threadLocalList.Count; }
  return num;
}

Поэтому, Count намного быстрее метода Any().

ConcurrentDictionary

GetEnumerator не создаёт новой коллекции, а использует ключевое слово yield для ленивой итерации по коллекции, поэтому Any() совершает всего одну итерацию:

public IEnumerator<KeyValuePair<TKey, TValue>> GetEnumerator()
{
  foreach (ConcurrentDictionary<TKey, TValue>.Node bucket in this.m_tables.m_buckets)
  {
    ConcurrentDictionary<TKey, TValue>.Node current;
    for (current = Volatile.Read<ConcurrentDictionary<TKey, TValue>.Node>(ref bucket); current != null; current = current.m_next)
      yield return new KeyValuePair<TKey, TValue>(current.m_key, current.m_value);
    current = (ConcurrentDictionary<TKey, TValue>.Node) null;
  }
}

Свойство Count блокирует коллекцию и подсчитывает количество элементов:

public int Count
{
  [__DynamicallyInvokable] get
  {
    int locksAcquired = 0;
    try
    {
      this.AcquireAllLocks(ref locksAcquired);
      return this.GetCountInternal();
    }
    finally
    {
      this.ReleaseLocks(0, locksAcquired);
    }
  }
}

private int GetCountInternal()
{
  int num = 0;
  for (int index = 0; index < this.m_tables.m_countPerLock.Length; ++index)
    num += this.m_tables.m_countPerLock[index];
  return num;
}

И чем больше элементов в коллекции, тем больше времени требуется на подсчет:

Method	_size	Mean	Scaled	ScaledSD
Any	10	37.79 ns	1.00	0.00
Custom	10	239.63 ns	6.34	0.18

Any	100	34.46 ns	1.00	0.00
Custom	100	823.62 ns	23.90	0.58

Any	1000	38.22 ns	1.00	0.00
Custom	1000	6,264.17 ns	163.92	2.09

Any	10000	35.57 ns	1.00	0.00
Custom	10000	24,819.31 ns	697.82	11.97

Профайлер показывает, что больше всего времени теряется на блокировках:

ConcurrentStack

GetEnumerator использует ленивое перечисление элементов, поэтому вызов Any() дешев:

private IEnumerator<T> GetEnumerator(ConcurrentStack<T>.Node head)
{
  for (ConcurrentStack<T>.Node current = head; current != null; current = current.m_next)
    yield return current.m_value;
}

В то время как Count просто подсчитывает количество элементов даже без блокировки:

public int Count
{
  [__DynamicallyInvokable] get
  {
    int num = 0;
    for (ConcurrentStack<T>.Node node = this.m_head; node != null; node = node.m_next)
      ++num;
    return num;
  }
}

ConcurrentQueue

Реализация GetEnumerator несколько сложна, но внутри используется ленивое перечисление. Count использует простые арифметические операции без блокировки. Можем использовать оба способа.

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

Универсальный метод для всех коллекций?

В классическом фреймворке (.NET 4.7.1) мы должны использовать Count или Any() в зависимости от коллекции.

В новых версиях .NET ситуация изменилась, вы можете ознакомиться с актуальным исследованием в статье Any() vs Count: часть 2.

Ссылки

Исходный код тестов

Неизвестный T-SQL

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

Несколько редко используемых, но вполне полезных функций MSSQL. Если вы никогда не слышали о функциях CHOOSE, ROW_NUMBER, RANK, DENSE_RANK, FIRST_VALUE, LAST_VALUE, LAG, LEAD, PERCENTILE_CONT и PERCENTILE_DISC, то ниже вы узнаете, какие полезные вещи можно сделать их помощью. Так же, я покажу несколько примеров использования выражений OVER и PARTITION BY в оконных функциях.

Подготовка

Создадим две таблицы Employees - информация о сотрудниках, Assessments - информация об изменениях зарплат сотрудников.

Employees

CREATE TABLE [dbo].[Employees]
(
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Name] [nvarchar](50) NOT NULL,
    [Age] [int] NOT NULL,
    [TeamName] [nvarchar](50) NOT NULL,
    [Position] [nvarchar](50) NOT NULL,
    [Department] [nvarchar](50) NOT NULL,
    [Salary] [int] NOT NULL,
    [Configuration] [int] NOT NULL,
    CONSTRAINT [PK_Employees] PRIMARY KEY CLUSTERED ([Id] ASC)
)

Assessments

CREATE TABLE [dbo].[Assessments]
(
    [Name] [nvarchar](50) NOT NULL,
    [Year] [int] NOT NULL,
    [Salary] [int] NOT NULL,
    CONSTRAINT [PK_Assessments] PRIMARY KEY CLUSTERED ([Name] ASC, [Year] ASC)
)

Заполним эти таблицы тестовыми данными:

INSERT INTO [dbo].[Employees]
(Name, Age, TeamName, Position, Department, Salary, Configuration)
VALUES
('Smith',25,'World','QA','RnD',30000,1),
('Wesson',20,'World','QA','RnD',50000,2),
('Gray',23,'OLAP','QA','RnD',45000,3),
('Black',31,'Flamp','QA','Flamp',60000,1),
('White',33,'World','Dev','RnD',70000,2),
('Constantine',29,'OLAP','Dev','RnD',120000,1),
('Gurken',32,'World','Dev','RnD',110000,1),
('Dunky',26,'Flamp','Dev','Flamp',110000,3)


INSERT INTO dbo.Assessments
(Name, Year, Salary)
SELECT
    e.Name,
    2016,
    e.Salary
FROM dbo.Employees e
UNION ALL
SELECT
    e.Name,
    2015,
    (e.Salary - 1000 * CAST(RAND(CHECKSUM(NEWID()))* 20 AS int))
FROM dbo.Employees e

CHOOSE

В таблице Employees есть колонка Configuration, которая может принимать одно из трех значений (1, 2, 3) - конфигурация рабочего места сотрудника (обычный PC, мобильная конфигурация или макбук соответственно). И если для хранения достаточно числового значения, то для отображения необходимо расшифровать его в строку. В классическом варианте можно создать временную таблицу из трех значений и сделать JOIN из нашей таблицы сотрудников:

CREATE TABLE #Configuration (Id int, Value nvarchar(10))
INSERT INTO #Configuration
VALUES
(1, 'PC'), (2,'Mobile'), (3,'Mac')

SELECT
    e.*,
    c.[Value]
FROM dbo.Employees e
INNER JOIN #Configuration c ON e.Configuration = c.Id

В результате получим именно то, что хотели, правда немного многословно: нам пришлось создать дополнительную таблицу и сделать соединение. Более простой вариант - использовать CASE-WHEN:

SELECT
    e.*,
    (CASE e.Configuration
        WHEN 1 THEN 'PC'
        WHEN 2 THEN 'Mobile'
        WHEN 3 THEN 'Mac'
    END)
FROM dbo.Employees e

Но благодаря функции CHOOSE этот код можно еще сократить и сделать более читаемым:

SELECT
    *,
    CHOOSE(e.Configuration, 'PC', 'Mobile','Mac')
FROM dbo.Employees e

Первый аргумент функции - индекс, по которому надо взять значение из оставшегося списка. Если индекс указывает на не существующее значение, то функция привычно вернет NULL. Все три варианта дают одинаковый результат. Вариант с CHOOSE выглядит предпочтительным для "расшифровки" перечислений, состоящих из небольшого количества значений.

ROW_NUMBER, RANK, DENSE_RANK

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

SELECT
    e.Name,
    e.Salary,
    ROW_NUMBER() OVER(ORDER BY e.Salary DESC) AS EmployeeId,
    e.Position,
    ROW_NUMBER() OVER(PARTITION BY e.Position ORDER BY e.Salary DESC) AS PositionId
FROM dbo.Employees e

Результат:

Итак, мы действительно получили рейтинг зарплат и даже с разбивкой по должности. Можно заметить, что некоторые сотрудники (Gurken и Dunky) получают одинаковую зарплату, но находятся на разных позициях рейтинга, что выглядит не логично. Для исправления этой ситуации есть функция RANK:

SELECT
    e.Name,
    e.Salary,
    RANK() OVER(ORDER BY e.Salary DESC) AS EmployeeId,
    e.Position,
    RANK() OVER(PARTITION BY e.Position ORDER BY e.Salary DESC) AS PositionId
    FROM dbo.Employees e

Цель этой функции - дать относительный порядок строки в наборе.

Как мы видим, теперь сотрудники с одинаковой зарплатой находятся на одинаковой позиции в рейтинге. При этом, следующий сотрудник (White) находится на четвертой позиции - эта функция учитывает пропуски. Если же нам не нужны пропуски, и следующий сотрудник должен стать третьим, то необходимо использовать функцию DENSE_RANK:

SELECT
    e.Name,
    e.Salary,
    DENSE_RANK() OVER(ORDER BY e.Salary DESC) AS EmployeeId,
    e.Position,
    DENSE_RANK() OVER(PARTITION BY e.Position ORDER BY e.Salary DESC) AS PositionId
FROM dbo.Employees e

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

FIRST_VALUE, LAST_VALUE

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

SELECT
    e.TeamName,
    MAX(e.Name) AS QAName
FROM dbo.Employees e
WHERE e.Position = 'QA'
GROUP BY e.TeamName

Получим вот такой результат:

Вместо функции MAX можно взять MIN, что не сильно изменит ситуацию. Подумав, что тестирование - это дело ответственное, решили выбрать самого старого по возрасту тестировщика из каждой команды. Это можно сделать таким способом:

SELECT
    e.TeamName,
    (
        SELECT TOP 1 
            e2.Name 
        FROM dbo.Employees e2 
        WHERE e2.TeamName = e.TeamName AND e2.Position = 'QA' 
        ORDER BY e2.Age DESC
    ) AS QAName
FROM dbo.Employees e
GROUP BY e.TeamName

Как мы видим, Smith старше, чем Wesson, поэтому и попал в нашу итоговую выборку. Но появился один подзапрос, который кажется лишним. Как нам поможет решить эту проблему функция FIRST_VALUE? Эта функция возвращает первую строку сортированного набора. А значит, можем из всех наших сотрудников оставить только QA, поделить по командам, отсортировать по убыванию возраста и выбрать первого:

SELECT
    e.TeamName,
    FIRST_VALUE(e.Name) OVER (PARTITION BY e.TeamName ORDER BY e.Age DESC) AS QAName
FROM [dbo].[Employees] AS e
WHERE e.Position = 'QA'

В результате получаем:

Почему получили две одинаковые строки (World, Smith)? На первый взгляд это кажется не логичным. Но если посмотреть на запрос без функции FIRST_VALUE, то мы увидим, что выбрали только всех QA (по условию WHERE), а их у нас как раз таки 4, и для каждого выбрали команду и самого старого QA в команде. Сделали немного задом наперед. Для нужного результата нам нужно использовать DISTINCT. Согласен, не самое подходящее использование функции, но все же. Функция LAST_VALUE работает аналогично, но возвращает последний результат набора.

NTILE

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

SELECT
    e.Name,
    e.Position,
    e.TeamName,
    NTILE(4) OVER(ORDER BY e.Id) AS NewTeamId
FROM dbo.Employees e

Каждый сотрудник получил NewTeamId - номер новой команды, в которую попадает сотрудник. Только вот в командах 1 и 2 собрались одни QA, а в командах 3 и 4 - только разработчики. Давайте распределим сначала сотрудников по их должности, для этого добавим выражение PARTITION BY:

SELECT
    e.Name,
    e.Position,
    e.TeamName,
    NTILE(4) OVER(PARTITION BY e.Position ORDER BY e.Id) AS NewTeamId
FROM dbo.Employees e

Теперь мы сначала распределили всех разработчиков по командам, а потом всех QA, и получили, что в каждой команде есть разработчик и тестировщик, что как минимум лучше, чем прошлый вариант. Если учесть человеческий момент, и собрать в новых командах людей, которые работали в старых командах вместе, то необходимо изменить способ упорядочивания для функции NTILE:

SELECT
    e.Name,
    e.Position,
    e.TeamName,
    NTILE(4) OVER(PARTITION BY e.Position ORDER BY e.TeamName) AS NewTeamId
FROM dbo.Employees e

Теперь видим, что в новых командах работают знакомые люди.

LAG, LEAD

Недавно прошла аттестация и сотрудникам повысили зарплату. В таблице Assessments есть информация о зарплатах сотрудников по каждому году, руководству для анализа необходимо узнать сумму, на которую каждому сотруднику сделали повышение. Обычно это решается соединением таблицы на саму себя с использованием смещения, в нашем случае - по году:

SELECT
    a.Name,
    a.[Year],
    a.Salary,
    a2.Salary AS Salary2015,
    a.Salary - a2.Salary AS Plus
FROM dbo.Assessments a
INNER JOIN dbo.Assessments a2 ON a.Name = a2.Name AND a.Year = a2.Year + 1

Ожидаемый результат:

Меняя выражение Year + 1 мы можем посмотреть повышение за последние 1, 2 и т.д. лет. При этом, если мы хотим одним запросом узнать повышение за год и за 5 лет, то нам придется сделать 2 соединения соответственно. Функция LAG позволяет получить значение предыдущей строки, LEAD - следующей. При этом, как параметр можно указать, на сколько строк нужно "вернуться" назад или вперед:

SELECT 
    a.Name,
    a.[Year],
    a.Salary,
    LAG(a.Salary, 1, NULL) OVER (PARTITION BY a.Name ORDER BY a.[Year]) AS Salary2015,
    a.Salary - LAG(a.Salary, 1, 0) OVER (PARTITION BY a.Name ORDER BY a.[Year]) AS Plus
FROM dbo.Assessments a

И так, мы указали в функции LAG, что нужно "вернуться" на 1 строку назад в отсортированном наборе. Мы разделили наш набор по сотрудникам и отсортировали по году. Естественно, для первой строки не будет предыдущего набора (а для последней - следующего), поэтому третий параметр функции как раз определяет это отсутствующее значение. Мы получили необходимый результат и еще строки за 2015 год. Мы не можем их отфильтровать в этом же запросе, т.к. это повлияет на результат выполнения функции LAG (для строк только из 2016 года нет предыдущего значения года, очевидно), поэтому обернем это еще в один запрос и отфильтруем:

SELECT
    *
FROM
(
    SELECT 
        a.Name,
        a.[Year],
        a.Salary,
        LAG(a.Salary, 1, NULL) OVER (PARTITION BY a.Name ORDER BY a.[Year]) AS Salary2015,
        a.Salary - LAG(a.Salary, 1, 0) OVER (PARTITION BY a.Name ORDER BY a.[Year]) AS Plus
    FROM dbo.Assessments a
) AS t
WHERE t.[Year] = 2016

И мы получили аналогичный результат. Здесь преимущество функции LAG над соединением в том, что мы можем легко сравнивать текущее значение со значением 1, 2, 3 или 5 лет назад просто поменяв одно значение параметра, при этом, можем все это вычислить одним запросом, который будет исполнен за один проход по таблице без соединений. Функция LEAD работает аналогично, но выбирает следующие строки.

PERCENTILE_CONT, PERCENTILE_DISC

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

SELECT
    e.Name,
    e.Salary,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY e.Salary) OVER () AS Median,
    e.Position,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY e.Salary) OVER (PARTITION BY e.Position) AS MedianInPosition,
    e.Department,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY e.Salary) OVER (PARTITION BY e.Department) AS MedianInDepartment,
    e.TeamName,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY e.Salary) OVER (PARTITION BY e.TeamName) AS MedianInTeam
FROM dbo.Employees e

Итак, одним запросом мы узнали, что наш мистер Black получает зарплату на 5000 меньше медианы по компании, но на 12500 больше чем медиана среди QA! Делая различные разделения в выражении OVER мы можем получить показатели по определенному подмножеству, или оставить это выражение пустым, что бы получить результаты по всему набору. В чем отличия функций PERCENTILE_CONT и PERCENTILE_DISC? PERCENTILE_CONT возвращает результат из непрерывного множества значений. Заметьте, что значение медианы 65000 не является чей-либо зарплатой в компании - это статистическое значение. Если же мы хотим использовать как медиану (или процентиль, в общем случае) значение из нашего набора, то необходимо использовать функцию PERCENTILE_DISC:

SELECT
    e.Name,
    e.Salary,
    PERCENTILE_DISC(0.5) WITHIN GROUP (ORDER BY e.Salary) OVER () AS Median,
    e.Position,
    PERCENTILE_DISC(0.5) WITHIN GROUP (ORDER BY e.Salary) OVER (PARTITION BY e.Position) AS MedianInPosition,
    e.Department,
    PERCENTILE_DISC(0.5) WITHIN GROUP (ORDER BY e.Salary) OVER (PARTITION BY e.Department) AS MedianInDepartment,
    e.TeamName,
    PERCENTILE_DISC(0.5) WITHIN GROUP (ORDER BY e.Salary) OVER (PARTITION BY e.TeamName) AS MedianInTeam
FROM dbo.Employees e

Теперь в качестве результата используется одно из значений исходного набора.