Оптимизация языка GC, есть идеи?

Question

Я довольно большой новичок, когда дело доходит до оптимизации. В текущей игре, над которой я работаю, мне удалось оптимизировать функцию и снизить нагрузку на процессор примерно на 0,5%, и это примерно так же «круто», как и раньше.

Моя ситуация такова: я разработал тяжелую физическую игру в MonoTouch, используя библиотеку оболочки XNA под названием ExEn, и, как мне кажется, мне было очень трудно добиться, чтобы игра достигла играбельной частоты кадров на iPhone4. (даже не хочу думать о iPhone3GS на данный момент).

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

Я использовал инструменты для профилирования производительности, и вот что я получил: http://i.imgur.com/FX25h.png Функции, которые потребляют наибольшую производительность, либо из физического движка (Farseer), либо из вызываемых ими функций оболочки ExEn XNA (особенно Vector2). .Max, Vector2.Min).

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

return new Vector2(Max(v1.x, v2.x), Max(v1.y, v2.y)) 

По сути, я чувствую, что застрял, и из-за моих ограниченных возможностей и понимания оптимизации кода я не уверен, какие у меня есть варианты или есть ли у меня какие-либо варианты (может быть, мне следует просто свернуться в позу эмбриона и плакать? ). С включенным и встроенным релизом LLVM я получаю в лучшем случае 15 кадров в секунду. Мне удалось довести игру до 30 кадров в секунду, снизив физическую точность, но это делает многие уровни просто неиграбельными, поскольку тела пересекаются и падают друг на друга.

Итак, мой вопрос: это проигранное дело или я могу что-то сделать, чтобы повысить производительность?

Answer 1

Я полагаю, что вы уже следуете советам по производительности в http://farseerphysics.codeplex.com/documentation :-)

• Похоже, что наиболее важным является уменьшение сложности вычислений обнаружения столкновений, т.е.не визуальные, а сталкивающиеся формы.В Unijty3D они называются коллайдерами, и вы можете прикрепить простой куб в качестве коллайдера к сложному человеческому телу.Я ничего не знаю о Фарере, но они, вероятно, имеют схожую концепцию (это называется тело?).

  Если возможно, попробуйте заменить вашего главного героя или другие сложные объекты на простые кубы и проверьте, повышается ли fps.

• Переключатели компилятора иногда повышают производительность.Будьте уверены, что не активированы параметры отладки (в проекте библиотеки C ++ я набрал 30 раз медленнее кода ).Убедитесь, что оптимизация armv7 включена и -O3 или -Os

• Следите за регистрацией операторов, поскольку они очень дороги для iPhone

[Обновление:]

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

• Как насчет других платформ?Где вы проводили тестирование на этапе разработки на симуляторе?Который из?Есть ли шанс запустить его на Android или Android-симуляторе или Windows Phone?Это даст вам подсказку, если это проблема для iPhone.

• Ах, я только что увидел, что ExEn все еще находится в состоянии перед выпуском, и финал будет запущен 21 июля, какОПЕРАЦИОННЫЕ СИСТЕМЫ.ИМО это меняет ситуацию: если ваше приложение работает нормально на какой-то другой сопоставимой платформе, тогда просто дождитесь релиза и попробуйте еще раз.Скорее всего, в предварительном выпуске, над которым вы работаете, все еще есть отладочный код.

Answer 2

Во-первых, любите свою игру на Windows Phone 7!

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