Автоматизировать тестирование производительности XNA?

Мне было интересно, какие у людей подходы или мысли были относительно автоматизации тестирования производительности в XNA. В настоящее время я смотрю только на работу в 2d, но это создает много областей, где производительность может быть улучшена с помощью различных реализаций.

Примером может быть, если бы у вас было 2 разных реализации пространственного разбиения, одно может быть быстрее другого, но без проведения какого-либо реального тестирования производительности вы не сможете точно сказать, какое из них (если вы не видели, что код был явно медленным в некоторых случаях). части). Вы могли бы написать модульный тест, который для данного периода времени продолжал добавлять / обновлять / удалять сущности для обеих реализаций и видеть, сколько было выполнено в каждом таймфрейме, и чем выше, тем будет быстрее (в данном примере).

Другим примером более высокого уровня может быть, если вы хотите увидеть, сколько объектов вы можете иметь на экране примерно, не превышая 60fps. Проблема с этим автоматизировать его вам нужно будет использовать скрытую форму трюк или другую вещь , чтобы пнуть в макет игры и чисто тест , какие части вы заботитесь о и отключить все остальное.

Я знаю, что на самом деле это не простой процесс, поскольку даже если вы можете автоматизировать тесты, на самом деле это зависит от человека, чтобы интерпретировать, если результаты достаточно эффективны, но как часть шага сборки вы могли бы запустить эти тесты и опубликовать результаты где-то для сравнения.

Таким образом, если вы переходите с версии 1.1 на 1.2, но изменили несколько базовых алгоритмов, вы можете заметить, что в целом показатель производительности повысился бы, то есть вы улучшили общую производительность приложения, а затем с 1.2 до 1.3 вы можете заметить что вы немного снизили общую производительность.

Кто-нибудь автоматизировал подобные вещи в своих проектах, и если да, то как вы оцениваете свои сравнения производительности на высоком уровне и какие платформы вы используете для тестирования? Если вы написали свой код так, чтобы его можно было тестировать / макетировать для большинства частей, вы можете просто использовать свои тесты в качестве механизма для получения некоторых результатов производительности ...

=== Редактировать ===

Просто для ясности, меня больше интересует, как лучше использовать автоматизированные тесты в XNA для отслеживания вашей производительности, а не играть в тестирование или догадки, вручную запустив вашу игру на компьютере. Это совершенно не похоже на то, играется ли ваша игра на оборудовании X, это скорее отслеживание изменений производительности при изменении игрового движка / фреймворка.

Как упомянуто в одном из комментариев, вы можете легко проверить, «сколько узлов я могу вставить / удалить / обновить в QuadTreeA в течение 2 секунд», но вы должны каждый раз физически просматривать эти результаты, чтобы увидеть, изменились ли они, что может быть хорошо и все же лучше, чем просто полагаться на игру, чтобы увидеть, заметили ли вы разницу между версиями. Однако, если вы добавите Assert, чтобы уведомить вас о сбое, если оно будет ниже, чем, скажем, 5000 за 2 секунды, у вас будет хрупкий тест, так как он затем контекстуален для оборудования, а не только для реализации. Хотя, как говорится, такого рода автоматизированные тесты действительно полезны только в том случае, если вы выполняете свои тесты как своего рода конвейер сборки, то есть:

Оформить заказ -> Выполнить модульные тесты -> Выполнить интеграционные тесты -> Выполнить тесты производительности -> Пакет

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

Я так понимаю, вы полностью хотите исключить «Запусти настоящую игру», так что в основном мой ответ дисквалифицирован с самого начала. Но, может быть, вы можете что-то от этого отнять, поэтому я пишу это независимо от того:

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

Итак, что у меня есть это:

• Профилировщик с областью действия (который помещает объект в стек, берет метку времени при построении и один при деконструкции), который используется для измерения того, сколько времени потребовалось для выполнения функции / области интересов
• Модуль, который хранит определенное количество профилированных выборок и выводит среднее значение по последним n выборкам в простой текстовый файл
• Внутриигровая командная строка, которая может использоваться для запуска игры, загрузки карты, изменения алгоритма, который используется в проверяемом модуле, изменения пути к файлу дампа профилировщика и многого другого. Указанная командная строка настроена для проверки определенного специального файла в исполняемом каталоге и загрузки его для выполнения извлеченной из него строки (как средство очень, очень грубого взаимодействия между процессами)

Таким образом, это позволяет мне запускать приложение из любой полуприличной среды сценариев (скажем, командной строки Windows через пакетные сценарии - но я на самом деле использую Ruby для этой цели), установить путь к файлу дампа, загрузить карту, оставить ее работает в течение нескольких минут, выйдите из запущенной игры, установите другой путь к файлу дампа, переключите используемый алгоритм, загрузите карту снова, промойте, повторите. Скрипт Ruby связывается с игрой в полете, создавая специальный файл, который ищет модуль командной строки, и помещая нужные команды в синтаксис, понятный ему в командной строке.

На самом деле я не использую непрерывную интеграцию в этом проекте прямо сейчас, но ничто не помешало бы мне использовать этот скрипт на Ruby для анализа сгенерированных журналов производительности и создания XML-совместимого с xUnit для связи с CI-системой, когда производительность неожиданно снизилась по какой-то причине ушел из строя и запускал скрипт при каждой полной сборке на сервере сборки.

Итак, моя игра не написана на XNA (это просто C ++ и DirectX), и этот подход не учитывает тот факт, что вы на самом деле не хотите запускать игру на своем сервере сборки. Он также далеко не так гибок, как то, к чему вы, вероятно, стремились, - но все же это аккуратный, не требующий высоких технологий подход к автоматизированному измерению производительности, который в некоторой степени дружествен к CI (при условии, что у него есть мощный сборочный сервер).

Редактировать: Что касается того, насколько я на самом деле выбрал этот подход - я сравниваю только измерения производительности, полученные из разных реализаций только этого одного модуля. Но вся система настроена таким образом, чтобы я мог сбросить любую одну из категорий, определенных для моей упрощенной среды профилирования, и использовать внешнюю среду сценариев для интерпретации результатов любым удобным для вас способом. Принимая аспект профилирования производительности из уравнения, я также намерен

• Проверьте правильность / согласованность всех ресурсов, загрузив все карты, содержащие все модели / текстуры / звуки, и проверив журналы движка на наличие чего-либо необычного.
• Проведите стресс-тестирование двигателя и просмотрите журналы на наличие непредвиденных ситуаций в течение нескольких часов / дней.

Я не вижу, что вы описываете как полезный инструмент. Как разработчик, простой показатель производительности практически бесполезен.

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

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

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

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