Если данные разбросаны по памяти, CPU каждый раз ждёт медленную RAM.
Почему Объекты разбросаны по памяти и связаны указателями, обращения к ним идут вразнобой → Следствие Данных нет в кэше CPU, и их каждый раз приходится читать из RAM (примерно в 100 раз медленнее) → На экране Та же работа обходится тику в несколько раз дороже, в тяжёлых случаях слоумо
Основной ответственный Команда разработки · Разработка сервера
Команда разработки: задачи
Размещать данные, которые часто используются вместе, подряд в памяти (data-oriented design).
На графике
Высоко с самого начала · время тика, загрузка CPU
Где смотреть
Запустить perf stat -d -p PID на процессе игрового сервера, измерить число инструкций за такт (insn per cycle) и промахи кэшей L1 и LLC, смотреть вместе со временем тика и загрузкой CPU
Подтверждает
CPU постоянно загружен, но insn per cycle низкий и промахов LLC много. Если в сборке с изменённым размещением данных время тика при том же онлайне заметно падает, причина подтверждена
Опровергает
Если загрузка CPU низкая, а тик медленный, дело в ожидании вне CPU: блокировки, ожидание ввода-вывода
perf-stat(1) — Linux manual pageperf С -p считает аппаратные события работающего процесса и показывает insn per cycle, -d добавляет события кэша данных L1 и LLC