Оптимизация конструкторов в АС3

ActionScript

Тут вот просили про оптимизацию написать, но поскольку писать про то, что знаешь несколько уныло и требует собраться с мыслями, оформить их, а написать что-то небольшое проще. Вот я и напишу про то, что недавно узнал.
Надеюсь, многие знают, что создавать объекты очень затратно и лучше пользоваться пулами. Теперь вот небольшое пояснение почему это настолько затратно, что многие и не догадывались.
Оказывается конструкторы не компилируются, а интерпретируются, что только прибавляет тормозов. Следовательно самый простой способ их оптимизировать — это выносить всю инициализацию из конструктора в отдельный метод, что также хорошо и для работы с пулами, когда надо проинициализировать извлекаемый объект.
Детальнее можно прочитать в группе руфлеш
Как это делать в деталях — дело каждого, но получается, что вызов инициализатора вне конструктора тоже будет быстрее, чем вызов его в конструкторе.
Остается пара вопросов, которые хотелось бы рассмотреть:
1) Получается, что такое удобное написание полей сразу с инициализацией значений тоже выполняется скриптом и добавляет тормозов, что скорее да чем нет.
2) Насколько получится прирост производительности если переопределить все конструкторы как методы. Не отпадет ли потребность в пулах? Хотя скорее прирост при использовании пулов будет все-равно оставаться (лень объяснять и зависит от того как плагин флеша с памятью работает).

+2
puzzlesea
27 мая 2010, 14:57

Комментарии (7)

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

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

В итоге, не очень понял как это «интерпретируется» конструктор, ибо это тот-же байсткод, те-же инструкции… Посмотрю позже руфлеш…

scmorr
27 мая 2010, 15:21
↓

То-есть вообще говоря вроде есть JIT, который байткод на лету компилит в ассемблер, и оттого все быстро становится. Тогда понятен был бы посыл. Однако я не думал что этот JIT уже работает и встроен.

scmorr
27 мая 2010, 15:29
↑
↓

Он не вроде а есть. И смысл в том, что конструкторы то и не компилятся. На руфлеше просто официальные комментарии есть.
А насчет GC я и сделал отступление, ибо в мэнеджед языках это тоже влияет.

puzzlesea
27 мая 2010, 17:10
↑
↓

Еще — выносить из конструктора все в init() метод тоже далеко не всегда быстро. Ибо — просто дополнительный вызов метода прилично жрет перфоманс (это тоже стандартный совет к оптимизации с многочисленными примерами). В итоге можно наоборот — ухудшить производительность.

scmorr
27 мая 2010, 15:39
↓

Я как-то делал тесты и там есть определенная грань когда вызовом метода работа ускоряется т.к. очевидно, что со своими полями класс работает быстрее. Ради инициализации пары полей лучше обращаться через экземпляр, а если надо много чего, то лучше методом.
Меня просто такой идиотизм доставляет все больше. Это ж как для оптимизации приходится извращаться.
Хотя и так вроде все работает для простеньких вещей. Но те-же партиклы норм не получишь потому что блендинг программный, хотя карты сейчас у очень многох с акселями и все держат аппаратно.

puzzlesea
27 мая 2010, 17:17
↑
↓

у меня обычно в конструкторе написано только что-то пдобное

public function ShopMenu() {

                        addEventListener(Event.REMOVED_FROM_STAGE, cleanUp, false, 0, true);
                        addEventListener(Event.ADDED_TO_STAGE, initShop, false, 0, true);
                }