Оптимизация подсчёта частот с LINQ CountBy

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

В .NET 9 пространство имён System.Linq получает CountBy — специализированный метод, существенно упрощающий эту операцию.

Старые накладные расходы

До .NET 9 подсчёт вхождений обычно требовал многословной цепочки LINQ-вызовов. Нужно было сгруппировать элементы, а затем спроецировать их в новый тип, содержащий ключ и количество.

// Before: Verbose and allocates group buckets
var logLevels = new[] { "INFO", "ERROR", "INFO", "WARN", "ERROR", "INFO" };

var frequency = logLevels
    .GroupBy(level => level)
    .Select(group => new { Level = group.Key, Count = group.Count() })
    .ToDictionary(x => x.Level, x => x.Count);

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

Упрощение с CountBy

В .NET 9 метод CountBy появляется прямо у IEnumerable<T>. Он возвращает коллекцию KeyValuePair<TKey, int>, избавляя от необходимости промежуточных структур группировки.

// After: Clean, intent-revealing, and efficient
var logLevels = new[] { "INFO", "ERROR", "INFO", "WARN", "ERROR", "INFO" };

foreach (var (level, count) in logLevels.CountBy(level => level))
{
    Console.WriteLine($"{level}: {count}");
}

Синтаксис не просто чище — он явно выражает намерение: мы считаем по ключу.

Влияние на производительность

Внутри CountBy оптимизирован так, чтобы не выделять группировочные бакеты, как делает GroupBy. В традиционном сценарии GroupBy среда выполнения часто создаёт объект Grouping<TKey, TElement> для каждого уникального ключа и поддерживает внутреннюю коллекцию элементов для этого ключа. Если у вас 1 миллион элементов и 100 уникальных ключей, GroupBy всё равно может проделать значительную работу по организации этих 1 миллиона элементов по спискам.

CountBy, напротив, должен лишь отслеживать счётчик. По сути он ведёт себя как аккумулятор Dictionary<TKey, int>. Он один раз итерирует исходник, увеличивает счётчик для ключа и выбрасывает сам элемент. Это превращает операцию с пространственной сложностью O(N) (с точки зрения хранения элементов) в нечто ближе к O(K) по памяти, где K — число уникальных ключей.

В сценариях с высокой пропускной способностью, например при анализе серверных журналов, обработке потоков транзакций или агрегировании данных датчиков, эта разница нетривиальна. Она снижает давление на GC, поскольку тяжёлые объекты-”бакеты” немедленно отбрасываются.

Краевые случаи и ключи

Как и GroupBy, CountBy использует компаратор равенства по умолчанию для типа ключа, если не указан другой. Если вы считаете по пользовательскому ключу-объекту, убедитесь, что GetHashCode и Equals правильно переопределены, либо передайте собственный IEqualityComparer<TKey>.

// Handling case-insensitivity explicitly
var frequency = logLevels.CountBy(level => level, StringComparer.OrdinalIgnoreCase);

Когда оставаться с GroupBy

Стоит отметить, что CountBy предназначен исключительно для подсчёта. Если вам нужны сами элементы (например, “дайте мне первые 5 ошибок”), GroupBy остаётся незаменимым. Но для гистограмм, частотных карт и аналитики CountBy в .NET 9 — более совершенный инструмент.

Применяя CountBy, вы сокращаете многословность и улучшаете шаблоны выделений в LINQ-конвейерах, делая его выбором по умолчанию для частотного анализа в современных C#-кодах.