60 FPS: профилирование игры

TPS — ticks per second, частота вызовов Update. Цель — 60: константа DefaultTPS в движке равна именно ей, и один тик получает бюджет около 16.6 миллисекунд. FPS — frames per second, фактическая частота вызовов Draw, которую движок подстраивает под вертикальную синхронизацию монитора. Числа связаны, но не склеены: если кадр вышел дорогим и FPS упал ниже TPS, движок не даёт логике замедлиться — он вызывает Update несколько раз подряд перед одним Draw, чтобы за секунду тиков всё равно набралось шестьдесят. Игрок видит это как рывки картинки при нормальной скорости игры.

Отсюда первый диагностический приём: TPS просел — виновата логика, то есть Update; FPS просел при целых TPS — виновата отрисовка, то есть Draw. Симптомы у игрока разные: низкий TPS ощущается как замедление всего мира, низкий FPS — как дёрганая картинка при верной скорости. Функции для HUD: ebiten.TPS() возвращает целевую частоту тиков, ebiten.CurrentTPS() и ebiten.CurrentFPS() — измеренные значения. Разница цен тоже разная: тик съедают аллокации и тяжёлые циклы, кадр — вызовы отрисовки и размеры картинок. Смешивать эти две истории — самый дорогой способ не починить ничего. Отсюда же правило бюджетов: любой вызов в цикле оплачивается из тех же 16.6 миллисекунд тика или кадра, и чем раньше числа HUD станут привычными глазами, тем дешевле обойдётся каждая следующая система игры — частицы, звук, тайлмапы.

Главный враг тика — сборщик мусора. Каждая новая строка, срез или структура, созданная в Update, попадает в кучу; чем чаще куча растёт, тем чаще GC запускается, а его циклы съедают бюджет тика рывками — TPS не падает плавно, а проваливается волнами. Типовые источники: append по срезу без заданной ёмкости, конкатенация строк в цикле, Sprintf в логике, срезы и map, создаваемые заново на каждом тике, замыкания в горячем коде. Лечение — переиспользование: выделить буфер один раз при загрузке и внутри тика сбрасывать длину конструкцией s = s[:0], а объекты, живущие коротко и массово, держать в пуле. Пул частиц из урока про частицы — ровно этот приём: частицы не создаются и не уничтожаются, а переезжают из свободного списка обратно в бой.

Проверить себя помогает go test с флагом -benchmem: бенчмарк на горячую функцию покажет число аллокаций на операцию, и цель — свести его к нулю или константе, не растущей с количеством сущностей. Компилятор Go часть мелких аллокаций убирает сам, рассчитывать на это не стоит: срез частиц на десять тысяч элементов он никуда не денет. Map в горячем пути тоже не заводят заново: встроенный clear очищает карту без новой аллокации, а известный заранее размер подсказывают при создании. Эффект второго порядка приятен: меньше мусора — короче паузы — ровнее TPS — предсказуемее кадр.

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

Со спрайтами честнее всего считается так: у DrawImage цена вызова, у большой картинки — цена заполненных пикселей. Движок батчит вызовы внутри — собирает отрисовку в пакеты к видеокарте, — поэтому сотня мелких спрайтов из атласа обычно дешевле, чем кажется. Но батчинг не делает вызовы бесплатными: тысячи DrawImage за кадр заметны на любом железе. Утверждение «один крупный спрайт дешевле сотни мелких» проверяется только замером: крупный экономит вызовы, но тратит заполнение, сотня мелких — наоборот. Атласы из урока про атласы снижают обе цены: меньше смен текстур — дешевле пакеты. Мелочь того же сорта: DrawImageOptions и GeoM не создаются на каждый вызов — структура опций заводится полем и переиспользуется, а нулевой options в аргументе честнее, чем пустой объект ради привычки. Сверяйте спор не мнением, а CurrentFPS до и после.

HUD отвечает на вопрос «какая половина цикла болит», но не отвечает «какая именно функция». Для этого в Go есть pprof: подключаете net/http/pprof, поднимаете локальный HTTP-сервер, и профилировщик доступен, пока игра работает. CPU-профиль снимается командой go tool pprof с адресом debug/pprof/profile?seconds=30: тридцать секунд движок собирает стеки всех горутин, включая игровой цикл, и сохраняет профиль в файл. Дальше top показывает самые горячие функции по доле процессорного времени, а list накладывает счётчики на строки конкретной функции.

Два правила снимка. Первое: профиль снимают под той же сценой, где наблюдается просадка — профиль пустого уровня расскажет про пустой уровень. Второе: секунды указывайте явно, тридцати обычно хватает, чтобы горячая функция вылезла в топ. Вся эта кухня живёт в локальном Go: профилировщику нужен настоящий процесс и сетевой интерфейс. Детальный разбор pprof, бенчмарков и трассировок — в продвинутом курсе Go; здесь достаточно связки сервер плюс одна команда. Там же лежит профиль кучи по маршруту debug/pprof/heap: он показывает, кто держит память, и хорошо дополняет счётчик HeapAlloc из HUD.

Техники урока работают только в связке с порядком действий. Первый шаг — всегда HUD: без него спор о производительности — обмен мнениями. Второй — локализация: TPS и FPS делят проблему пополам, pprof доводит до функции. Третий — правка одного подозреваемого за раз: починили, померили, сравнили; две правки за раз смешивают эффекты, и вы не узнаете, которая помогла. Четвёртый — откат: если правка не изменила числа, она вернулась из кода, каким бы умной ни казалась.

Бюджет стоит держать в голове арифметически: 60 тиков и 60 кадров в секунду — это около 16.6 миллисекунд на каждый, и любой вызов в цикле стоит свою долю этих миллисекунд. Оптимизация, которая усложняет код ради выигрыша в долю процента, платит читаемостью за ничто; правка, которая убирает тысячу аллокаций на тик, окупается с лихвой. Разницу между этими случаями знает только замер, поэтому HUD не демонтируется после урока — он остаётся в проекте флагом до самого итогового проекта, где пригодится при первой же волне врагов. Пятый шаг — календарь замеров: числа снимают заново после каждой крупной добавки — новой системы, волн врагов, смены разрешения, потому что бюджет съедается тихо и постепенно.