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

8

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

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

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

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

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

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

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

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

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

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

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

Grofit
источник
+1 отличный вопрос. Я еще этого не сделал, но скоро надо.
ashes999
Просто чтобы прояснить, я на самом деле не говорю о профилировщиках или внешних инструментах, хотя это может быть дополнительной вещью, чтобы помочь диагностировать медленные секции и т. Д. Я думаю больше об использовании ваших модульных тестов, чтобы дать вам некоторый контекст относительно того, Вы также улучшаете производительность, чтобы вы могли реализовать новый алгоритм поиска пути и сразу же протестировать его изолированно с вашей предыдущей версией, и сравнить цифры, мгновенно сообщающие вам, что вы улучшили его или потратили свое время, даже не прибегая к его интеграции. в основной проект и развернуть его.
Грофит
ваш вопрос кажется немного запутанным; Вы говорите об общем измерении производительности, которое можно сделать БЕЗ испытаний; но вы также можете написать такие тесты, как «тест Х происходит менее чем за 3 секунды».
ashes999
Да, и что «тест X происходит менее чем за 3 секунды» идет по правильному пути, но вместо такого теста, как «Сколько узлов я могу вставить в четырехугольное дерево за 5 секунд», результат для одной сборки может быть 10000, а следующая сборка может быть 5000. Увидев это, вы сразу же можете принять обоснованное решение, если вы ввели проблему. Проблема для меня в том, что вся эта информация хороша, но вы должны посмотреть на нее. Поскольку добавление assert для <7500 во времени может показаться хорошим, но если вы запускаете его на другом компьютере, оно может не пройти, но в действительности РЕАЛИЗАЦИЯ не медленнее.
Грофит

Ответы:

2

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

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

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

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

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

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

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

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

  • Проверьте правильность / согласованность всех ресурсов, загрузив все карты, содержащие все модели / текстуры / звуки, и проверив журналы движка на наличие чего-либо необычного.
  • Проведите стресс-тестирование двигателя и просмотрите журналы на наличие непредвиденных ситуаций в течение нескольких часов / дней.
Koarl
источник
1
Вся хорошая информация, дал вам +1. Судя по всему, все, что вы делаете выше, может быть легко сделано в виде интеграционного теста. Единственное, о чем вам нужно беспокоиться, это макетирование реальной игры / симуляции. Как только вы сделаете свои компоненты движков / фреймворков изолированными, чтобы их можно было протестировать в их собственном контексте, я и пытаюсь это сделать. Поскольку я не хочу тестировать производительность своей игры, поскольку она постоянно меняется, среда, однако, меняется редко и может быть легко настроена для запуска заданного количества сценариев, как вы упомянули.
Грофит
Спасибо. Как указывают на то, чего я хочу достичь в будущем, я стремился автоматизировать то, что происходит в реальной игре - результат оказался весьма удобным и для измерения производительности.
Koarl
0

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

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

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

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

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

AAAAAAAAAAAA
источник
3
Если вы следуете типичному подходу в стиле CI, когда вы запускаете свое программное обеспечение через сервер сборки, вы всегда будете тестировать на одной и той же машине, поэтому всегда на одном и том же оборудовании, которое даст вам базовые данные для ваших цифр. Поскольку это было направление, из которого я действительно шел. Вы говорите, что вам не нужен инструмент для определения изменений производительности между сборками, и это правда, что вы можете запустить его самостоятельно и увидеть разницу, но было бы здорово, если бы ваша система сборки или ваш текущий компьютер могли дать вам эти цифры без вашего ведома. делать что-либо кроме запуска теста.
Грофит
Если вы менее серьезно относитесь к тестированию, вам нужно несколько разных тестовых машин. В любом случае, в чем собственно проблема? Вы не знаете, как запрограммировать тест в игре?
аааааааааааа
Нет проблем как таковых, я просто пытаюсь получить информацию о том, как некоторые люди применили это к своим проектам. Я не думаю, что наличие отдельных машин помогает в любом случае, так как вы на самом деле не тестируете, чтобы увидеть, работает ли он со скоростью 30 кадров в секунду на низком оборудовании и 60 кадров в секунду на быстром оборудовании. Вы берете оборудование из уравнения и ТОЧНО смотрите на свой движок / исходный код. На самом деле не должно иметь значения, тестируете ли вы на 486 или четырехъядерном ядре, так как вы тестируете одну сборку против другой, а не один набор аппаратного обеспечения снова против другого.
Грофит
3
Я должен немного договориться и с Grofit, и с eBusiness. Автоматизированные тесты важны, особенно в больших проектах, так что, когда любая сборка проходит, вы будете знать, что что-то повлияло или помогло производительности, и это в идеале делается на одной машине. По крайней мере, для компьютерных игр вам также нужно тестировать самые разные аппаратные средства, ваши автоматические тесты могут показывать отличную производительность, но затем вы запускаете свою игру на старом графическом процессоре или обнаруживаете, что работаете с виртуальной памятью, и все это внезапно приводит к снижению производительности. Вы должны быть в состоянии проверить эти вещи, прежде чем они попадут в руки клиентов.
Ник Фостер
@Grofit Дело в том, что это может быть просто старая машина, которая ломает сборку. Не случайно, что изменение не оказывает существенного влияния на производительность нового компьютера или даже является улучшением, в то время как это же изменение полностью препятствует запуску игры на старом компьютере. Вы не можете вывести оборудование из уравнения, нет такой вещи, как производительность изолированного кода. Но если вы хотите настроить автоматический тестовый запуск только на одной машине, по крайней мере, сделайте это на старом юнкере, это даст вам больше шансов на провал теста.
aaaaaaaaaaaa