Показать сообщение отдельно
Старый 18.11.2011, 00:29
expl вне форума Посмотреть профиль Отправить личное сообщение для expl Найти все сообщения от expl
  № 6  
Ответить с цитированием
expl

блогер
Регистрация: Feb 2006
Сообщений: 1,474
Записей в блоге: 3
Цитата:
То есть, насколько я понимаю, timer живет до тех пор, пока тикает и пока имеет слушателя события
По идее, зависит от реализации флешплеера, теоретически его может снести и до того, как закончит тикать - ссылок то на него нет, он только сам на слушатели ссылается. Дисплей-объект, например, рассылающий ENTER_FRAME, может спокойно кануть в лету послав десяток-другой событий.
Однако:
Цитата:
Timer против GC.
Запись от dimarik размещена 21.02.2011 в 21:41
Обновил(-а) dimarik 13.03.2011 в 21:29
Все просто. Пока тикает экземпляр Timer, он не может быть удален сборщиком мусора (Garbage Collector).
Ну а насчёт утечек - если бы до таймера не добирался GC даже при его неактивности - это была бы принципиальная проблема flashplayer'а. Т.е. никаким боком нельзя было бы убрать ненужные таймеры.

С другой стороны, если вы пользуетесь одним таймером, а не создаете по 5 штук в секунду - конечно это будет лучше для производительности - ни память каждый раз выделять не надо, ни gc сильно не напрягается (вопрос только в том, сколько будет жрать чудная система в стиле, предложенном gloomyBrain, зато отписаться можно будет от ставшей ненужной комманды)

P.S. Связный список, он ведь тоже подразумевает создание объекта - узла списка при добавлении элемента, а время поиска произвольного узла перед тем как удалить - явно не быстрее чем в массиве. Можно, конечно навернуть словарик соответствия узел-елемент, тогда время доступа зависеть от количества элементов не будет. Но если элементы повторяются... Скорость доступа замедляется на время вызова функции (тут вам не haXe с inline-ами). Короче без тестов производительности я бы это дело не рискнул встраивать - обошелся бы обычным массивом

P.S.2 Самый эффективный способ - это когда список организуется с самими хранимыми элементами в качестве узлов - тогда создавать ничего не надо - элементы уже созданы, просто на них навешаны prev и next поля. Только теперь элемент не может храниться в 2-х списках одновременно. Плюс т.к. поле не может быть частью переменной - интерфейс элемента списка использовать нельзя - только наследование или узкозаточенный список под конкретные элементы.


Последний раз редактировалось expl; 18.11.2011 в 00:48.