Почему один и тот же код у одного тормозит на тысячах записей, а у другого работает на миллионах

Допустим, программа пересчитывает стоимость заказов:

сумма = цена × количество − скидка

В одном проекте такой цикл тормозит на 50 тысячах записей, в другом обрабатывает миллионы. Формула одинаковая. Разница — в структуре данных и их раскладке в памяти.

Тяжелые объекты

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

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

Программа тратит время не на вычисления, а на перемещение данных.

Данные под конкретную операцию

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

Формула не изменилась, а работа ускорилась.

Например, миллион объектов по 200 байт занимает около 200 МБ без учета служебной нагрузки. Если для расчета нужны только два числовых поля, достаточно обработать примерно 16 МБ полезных данных.

Важно и то, сколько записей мы проверяем

Представим систему зависимых значений. Изменение одной записи должно пересчитать еще пять.

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

В первом случае стоимость обновления растет вместе со всей системой. Во втором — зависит от количества реально затронутых данных.

Что проверить, если система тормозит

- Какие поля действительно нужны операции.

- Не загружаются ли остальные поля за компанию.

- Лежат ли данные последовательно или разбросаны по памяти.

- Не обходится ли вся коллекция ради нескольких элементов.

- Можно ли построить индекс или граф связей.

- Сколько временных объектов создается при обработке.

- Как код работает на реальном объеме, а не на тысяче тестовых записей.

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

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

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

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