Мобильные платформы и бассейн с объектами
 

Первый раз делаю игру, которую планируем портировать на IOS и другие мобильные платформы.
Пишут, что необходимо использовать object pool, для того чтобы избегать слова new во время выполнения приложения, так как это очень трудоемкая операция.
У меня, к сожалению, нет Айфона, чтобы потестить что он может.
И возник вопрос:
В каких случаях необходимо использовать object pool ?
Слово new критично только для визуальных объектов ( как в настольных приложениях ) или для всех объектов вообще ?

Использовать object pool нужно только тогда, когда создается и удаляется большое количество объектов. Для всех других случаев сборщик мусора должен сработать оптимально.

Вот хороший урок на эту тему. Действительно, object pool делает работу приложения более стабильной

http://active.tutsplus.com/tutorials...#comment-51246

Спасибо за ответы.
Но меня интересует, что конкретно такого тормознутого происходит при создании нового объекта.
Выделяется память в стеке под ссылку (тут я так понимаю все быстро )
Выделяется память в куче под сам объект ( может тут ?)
И создается сам объект , если тут тогда имеет ли значение тип объекта
1. Обычный объект не визуальный
2. Натив флеш Sprite или MovieClip ( тут создается новый экземпляр картинки )
3. Stage3D объект из текстур, текстуры из текстуре атласа кот создан при запуске приложения. ( тоесть вроде бы новых экзепл не создается, только ссылки )

Возьмите профайлер и посмотрите. Или тесты сделайте. Если у вас нет времени на профайлер и тесты, значит, оптимизацию проводить еще рано.

Вроде бы нет. Память на стеке выделяется при входе в метод, а не в процессе работы.

Зависит от кучи. Вообще это тоже быстрая операция. Насколько быстрая - зависит от используемой кучи (во флеше вроде бы не самая быстрая куча).

Имеет. И не только тип объекта, но и используемая платформа. Важно наличие "native" ресурсов, т.е. системных ресурсов и т.п.
Есть еще Sound, network connection и т.п.
Здесь может быть. Выделение системных объектов. Зависит и от наличия ускорения, например (объекты могут копироваться в видеопамять).
Здесь тоже могут быть вызовы системных методов для аллокации соответствующих структур в видеоускорителе.

Но в целом все операции достаточно быстрые. И ответ на ваш начальный вопрос будет: до тех пор, пока проблемы с производительностию (и их причны) явно не обозначены, object pool использовать не стоит. Есть всего одно нормальное показание к его использованию - объекты с заведомо тяжелой инициализацией, которые при этом часто используются (соединения с базой данных и т.п.). У вас таких изначально нет, так что пулы делать не стоит. Кроме того, совсем не факт, что именно аллокации объектов будут узким местом. Возможно, 90% всей работы будет отрисовка и нужно оптимизировать ее. Или будет неоптимальный алгоритм, который нужно оптимизировать.

И еще. Излишние пулы могут ухудшить производительность, а не улучшить. Пулы с низкой степенью использования (всегда много свободных объектов) повышают нагрузку на память, повышают частоту вызовов сборщика мусора и усложняют ему работу (нужно больше объектов убирать). Так что все оптимизации нужно делать одновременно с измерениями производительности приложения.

Шикарный ответ, спасибо :)
Мне просто кажется, что объекты с заведомо тяжелой инициализацией во флэш это спрайты и мувики, во всяком случае в Windows, но думаю в IOS также. Не думаю, что при создании объекта с 5 св-ми числами будут тормоза.
Но так как у меня игра на Старлинге, а там объект Sptite это просто ссылка на кусочек в текстуре атласе, думаю никакой необходимости в бассейне нет.