Снапшот индекса на 1 млн локаций: копия дороже самой работы

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Выбор контейнера и кэш-локальность могут съесть весь выигрыш от распараллеливания — оптимизировать надо старт, а не объём данных.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Есть тип задач, где всё ломается не на алгоритме, а на подготовке к нему. Игровая симуляция: основной поток считает тик, фоновые крутят свою логику на снапшоте состояния. Чтобы фоновые не лазили в живые данные, им отдают копию индекса «локация → сущности». Пока объектов мало, схема работает. Потом стратегия доживает до середины партии, сущности плодятся, локаций становится миллион — и снапшот начинает стоить дороже, чем вся работа, ради которой его вообще затевали.

Цифры из разбора жёсткие. Копирование индекса — 90 мс. Полезный проход по нему — 14 мс. Распараллелили ради четырнадцати миллисекунд и отдали девяносто просто за право начать.

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

Это не про игры. Это про любую систему, где вы строите снимок данных для параллельной обработки: отчётность, пересчёт остатков, ночная аналитика, переиндексация каталога. Логика одна — вы платите за старт больше, чем зарабатываете на самом проходе.

Что именно дорожает

Соблазн списать всё на объём памяти. Мол, данных стало много, копия тяжёлая. Объём тут вторичен. Главный виновник — паттерн доступа процессора к данным. Индекс на привычном vector<vector<...>> — это массив указателей на отдельные массивы, разбросанные по куче. Когда вы копируете такую структуру, процессор не читает память линейно, а прыгает: за одним блоком, за другим, за третьим. Каждый прыжок — промах кэша. На маленьких данных эти промахи незаметны, потому что всё помещается в кэш и прыгать особо некуда. На миллионе локаций прыжков становится столько, что копирование превращается в прогулку по всей оперативной памяти.

Стандартные контейнеры тут разоряют на пустом месте, и виноват даже не объём памяти, а то, куда процессор вынужден прыгать за данными.

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

Что это меняет для бизнеса

Если вы руководите продуктом или командой, которая пишет бэкенд, вывод из этой истории прикладной. Когда система начинает тормозить на росте данных, первая реакция обычно — «давайте распараллелим» или «давайте докупим железо». Оба хода лечат симптом. Проблема может сидеть в том, как вы готовите данные к работе, а не в том, сколько у вас ядер.

Практический признак: если время старта задачи растёт быстрее, чем время самой обработки, вы оптимизируете не то. Классический маркер — профиль, где подготовка снимка, сериализация, копирование структур занимают больше, чем полезная логика. В таком профиле бессмысленно добавлять потоки: вы масштабируете ту часть, которая и так дешёвая, а дорогую оставляете как есть.

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

Куда смотреть, если узнали свою систему

Направление, которое подсказывает разбор: ужимать данные так, чтобы старт перестал съедать выигрыш от многопоточности. Это значит — хранить индекс в форме, близкой к линейной, чтобы копирование и проход шли по непрерывной памяти. Плоские массивы вместо вложенных. Числовые идентификаторы вместо указателей. Данные, уложенные рядом, а не разбросанные по куче.

Проверить гипотезу можно без переписывания всей системы. Возьмите одну горячую структуру, замерьте отдельно время её копирования и время полезной работы на ней. Если копия доминирует — вы нашли точку, где лежат ваши девяносто миллисекунд. Дальше вопрос инженерный: как уложить те же данные плотнее, не потеряв удобство кода.

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

Брать или подождать

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

Подождать, если данные небольшие и всё живёт в кэше, или если узкое место в другом месте — в сети, в базе, в бизнес-логике. Перекладывать структуры ради красоты не нужно.

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

FAQ

Это только про игры?

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

Проблема в объёме памяти?

В первую очередь — в паттерне доступа. Процессор вынужден прыгать за разрозненными блоками, и это дороже, чем сам объём данных.

Поможет ли больше потоков?

Нет, если узкое место — подготовка снимка. Вы ускорите дешёвую часть и оставите дорогую как есть.

Надо ли сразу переписывать структуры?

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

Что заменить в первую очередь?

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

Если у вас в проекте есть задача, где подготовка данных съедает время, отведённое на саму работу, — это повод посмотреть на структуры хранения, а не на количество ядер. Начните с одного замера: сколько стоит копия и сколько стоит проход. Разница в шесть раз, как в разобранном случае, обычно видна сразу.