Потоки в Unity3D — измеряем производительность

Привет!
Иногда меня спрашивают об отложенных действиях или о многопоточности в Unity3D и обычно я советую обратить внимание на класс Coroutine, благо он позволяет решать большинство повседневных задач, связанных с задержками и проч.
Однако, иногда при разработке действительно требуется настоящая многопоточность, при поиске пути, например.
Поэтому я решил сделать на скорую руку небольшой тест, в котором можно было бы пощупать многопоточность и сравнить производительность исполнения кода в одном (главном) потоке и в многопоточной реализации. Для начала я поискал какие-нибудь менеджеры потоков, чтобы не велосипедить и наткнулся на простецкий (но в моем случае, удобный) класс Loom от whydoidoit.

Далее я по-быстрому слепил приложение, скомпилировал его под разные платформы (в архиве в конце статьи есть бинарники для всех основных платформ и сорцы самого проекта) и посмотрел на результаты. . Некоторые мне показались интересными, поэтому я решим ими поделиться, может быть кому-то это будет полезно.

Вообще код, который пытался нагружать CPU прост как пробка — я просто пробегаюсь по приличному массиву экземпляров Vector3D (10 000 000 элементов под десктопами и 1 000 000 под мобилами):

private void Run()
{
const float scale = 432.654f;

for (int j = 0; j < arrayLength; j++)
{
Vector3 v = vertices[j];

v = Vector3.Lerp(v * scale / 123f * v.magnitude, v / scale * 0.0123f * v.magnitude, v.magnitude);

vertices[j] = v;
}
}

Как видите, «начинка» цикла по сути ничего конкретного не делает — просто случайный набор всяких медленных вещей)
Так же я добавил на сцену модельку муравья (привет создателям примеров для Away3D! :)), которая крутится каждый Update(), дабы можно было сразу увидеть — когда приложение подвисает, «задумываясь», а когда — нет.

JTMLjQ0

Как я ранее сказал, я провел некоторые тесты на подручном оборудовании, проверял скорость работы как в синхронном режиме (выполнение в главном потоке), так, и в асинхронном (массив бьется на столько равных частей, сколько ядер доступно приложению и каждая часть обрабатывается в отдельном потоке), и получил я такие результаты (S — синхр, A — асинхр):
Читать далее

AIR vs. Unity3D. Кто быстрее? (Обновление 1)

Обновление 1: вылил немного сорцов (см. в конце статьи).

Привет!
Да, давно не писал, блаблабла.. К делу! =)

Иногда таким цветом я буду указывать на файлы из архива (ссылка на который приведена в конце статьи), которые относятся к текущему разделу.

В последнее время я все чаще замечаю как выходцы из мира Flash-разработки начинают интересоваться Unity3D, да и сам я в последнее время работаю с Unity всё больше и всё плотнее.
И как по мне — так это очень здорово — расширять свой кругозор, изучать новые языки (надеюсь, большинство пришедших из Flash-разработки делают правильный выбор в пользу C#), вливаться в новое комьюнити, решать новые задачи и т.д.!
Однако, многие нынешние флэшеры всё ещё сомневаются — стоит ли пробовать Unity3D, тратить время на изучение технологии… Зачастую, эти сомнения основаны на неясности относительно разницы в производительности приложений на Unity3D по сравнению с AIR, вот о ней я и расскажу в этой статье, чтобы помочь им определиться.

Примеры в статье я буду компилировать с помощью AIR 3.6 и последней Unity3D 4.1 с максимально приближённым функционалом и внешним видом.
Я сравню их производительность на относительно медленном GalaxyTab 10.1, и некоторые тесты проведу в десктопном режиме.

Интро

Итак, начнем с пустых проектов.
В Юнити проекте для измерения FPS будем использовать самописный fps-ометр, который рисует количество FPS на GUIText.
В AIR проекте будем использовать разные fpsометры — в основном будем брать статсы, встроенные в используемые фреймворки для максимальной совместимости.
Собираем релизные версии apk (во FlashDevelop’е собираем captive-runtime вариант).
Выливаем обе apk на девайс, смотрим:
Читать далее