Разработчик, описавший попытку ускорить Brotato на маломощном устройстве, сделал вывод: качество тестового стенда определяет ценность оптимизации. Идея, показавшая выигрыш на несопоставимых прогонах, может оказаться ложным улучшением.
Почему первая попытка не дала надёжного ответа
Автор начал с тяжёлого игрового сценария и предполагаемого узкого места — физических расчётов. Эксперименты с упрощённой обработкой столкновений и объединением графических ресурсов на одном устройстве показали улучшение, но при переносе на другое устройство заметного выигрыша не обнаружилось.
В первоначальных замерах не хватало метаданных сборки, нескольких сценариев, повторных прогонов и сырых покадровых данных. Средняя скорость скрывала редкие длинные кадры. Даже одинаковый seed не гарантировал воспроизводимость всех условий.
Что вошло в новый стенд
- Фиксированные сценарии с разной нагрузкой на физику и отрисовку.
- Повторения и прогрев перед измеряемыми запусками.
- Идентификатор сборки и параметры устройства.
- Сохранение сырых метрик для повторной обработки.
- Сравнение только тех записей, условия которых совпадают.
Продолжительность сценария привязывали к выполненной симуляции, а не только к настенным секундам. Это помогало отличать реальное ускорение от ситуации, когда программа просто выполнила меньше расчётов.
Медиана и длинные кадры
Медиана показывает центральное значение выборки, а P95 и P99 помогают увидеть хвост распределения. Для времени кадра критичны большие значения: редкий длинный кадр может испортить ощущение игры, даже если средний FPS выглядит приемлемо.
Процентиль сам по себе не доказывает устойчивость результата. Для этого нужны повторения, одинаковые условия и оценка разброса между запусками.
Как менялась гипотеза
По результатам на новом стенде замена физического сервера не давала ожидаемого выигрыша. После этого автор искал лишние пары столкновений, повторные вычисления и мелкие покадровые вызовы.
Отдельно проверялась отрисовка: снижение разрешения и временное скрытие групп объектов помогали различить нагрузку GPU и расходы на подготовку множества команд. Затем вернулись к атласам, объединению отрисовки и эффектам частиц.
Такая последовательность соответствует общему правилу: сначала найти ограничивающий участок, затем изменить его и снова измерить. Профилировщик создаёт накладные расходы, поэтому его показания сопоставляют с отдельными контрольными прогонами.
Что переносится в другие проекты
Из кейса не следует, что любой игре нужны конкретные структуры вроде хеш‑сетки, другого BVH или MultiMesh. Замена структуры может улучшить один сценарий и ухудшить другой. При объединении объектов возникают собственные ограничения, например общая видимость группы вместо независимого отсечения отдельных экземпляров.
Переносимая часть метода — сохранять условия и данные, проверять несколько сценариев и отказываться от гипотез, которые не подтверждаются. Заявленные результаты относятся к конкретным устройствам и версии игры; независимый бенчмарк здесь не проводился.
