wvxvw,
читал про флексовый профйлер, но, к сожалению, в haXe его не получится использовать.
Может есть профилировщика, которые работают со скомпилированными флешками?

Fillini,
ctrl+alt+delete — не самый точный детектор утечек. Хотя проверилял и им. Память «жрется», но достаточно медленно.

>листенеры правильно писать так
Странная фраза. Если такой набор параметров единственно правильный, как вы говорите, то почему тогда их можно изменять? Я за сомневался и решил прочесть справку.

Вы рекомендовали всегда подписываться на события так:
Это значит, что useCapture = false, priority = 0 а useWeakReference = true.

Первые два параметра такие же по-умолчанию, разница только в useWeakReference.

Fillini, почему нужно всегда использовать useWeakReference?

>так же не забываем очищать DisplayList.
А где это надо делать?


А нет ли возможности управлять сборщиком мусора? Удалять вручную или по команде?

Добавлено через 2 часа 26 минут
Нашел причину тормозов.

Причина, конечно, была в руках. Проблема была в том, что из-за ошибки перерисовка вызывалась слишком часто. При плее вместо 1 раза каждые 100 мс, делалось 3-4 перерисовки.

Тем не менее, думаю вопрос закрывать не стоит, так как, я думаю, исправление ошибки просто значительно растянуло во времени наступление тормозов.

параметр useWeakReference в листенерах говорит GC о том что как только объект был удален с DisplayList, и все ссылки на него выставлены NULL он становится доступным для сборки мусора.
GC вручную управлять невозможно.

Очищать DisplayList:
Например есть какой нибудь мувик служащий контейнером в который постоянно добавляется содержимое (addChild()). Объект не может быть удален из памяти пока:
1. Есть хоть одна ссылка на этот оъект
2. Есть хоть один не отписанный листенер. Чтоб эти принебреч используем useWeakReference
3. Объект находится в DisplayList.

чтобы удалить объект из DisplayList. вызываем removeChild, removeChildAt

Благодарю Fillini, просмотрю код, но у меня только мувик-курсор меняется. Все остальное создается один раз.