![]() |
влияет ли количество слушателей на производительность
есть однотипные объекты расположенные на сцене, по клику, наведению на каждый происходят действия. Интересует вопрос производительности, что лучше повесить на родителя слушателя, ловить события проверять цель(target) и производить действия через публичные методы объекта, или же можно при создание объекта в нем определять слушателей которые бы выполняли всю работу без участия родителя?
|
производительности или скорости реакции на event ?
|
без участия родителя, действия Вам проводить те же самые. а на всплытие одного события тратиться не так уж много времени. то есть это время можно вообще не учитывать, так как событие будет пытаться всплыть всё равно, и не важно где оно найдёт слушателя, в родителе или в самом объекте. так что вы скорее потратите больше ресурсов на постоянные подписки и отписки.
Добавлено через 42 секунды Crenth, это ваще бессмысленный вопрос =) скорость реакции будет одинакова в обоих случаях. |
мне просто важен момент связанный с расходом памяти, по поводу подписки отписки тут все просто стараюсь в каждом классе создавать метод зачищающий все слушатели перед его зануливанием.
почему спрашиваю: может быть такая ситуация что на экране появится около 500 объектов и вот тут и хотелось бы понять какой вариант выбрать? |
Терминологически не согласен.
производительность - количество однотипных операций в единицу времени. скорость реакции - интервал между событием и реакцией на него. очень многое зависит от того, как реализованы внутренние механизмы FP. Можно кривое всплытие написать. А можно криво написать обработку события родителя. Рекомендую тупо проверить оба варианта, нагрузив ваше приложение. Теоретический ответ может дать только разработчик |
по поводу самого всплытия тут как раз мне кажется что производительность мало различима, она как я думаю зависит от вложенности объектов... а она не настолько глубока в любом из проектов
|
Crenth, рекомендую начать читать про специфику ФП. и не давать советов в область, в которой Вы ничего не понимаете.
random13, Вы внимательно прочитали мой пост? |
BlooDHounD, у вас есть право забанить мои реплики в форуме. Однако, не нужно давать мне советы не по теме
|
Цитата:
Цитата:
|
Цитата:
|
подписка делается ведь при создании каждого отдельного из кучи однотипных объектов ?
а отписка, соответственно, при уничтожении каждого. не думаю, что с точки зрения объема исходного кода этот способ сложнее. он даже может оказаться гибче... но выяснить ресурсоемкость первого и второго подходов можно только экспериментальным путем... P.S. думаю, что "слушатель" представляет собой несколько байт и ни грамма исполняемого кода. |
orcpochta, об этом BlooDHounD и говорит "вы скорее потратите больше ресурсов на постоянные подписки и отписки"
|
Цитата:
|
просто при этом тоже получается что наш объект не что то самостоятельное а очень сильно завязанное на внешнем поведение, или это есть хорошо?
|
Цитата:
я как-то испытывал эту схему еще в 8 флеше и у меня бодро бегало 50 на 50 танков (в смысле по 50 в двух командах) по клеткам не наезжая друг на друга и радостно друг-друга убивая с эффектом разлетающихся осколков |
так ... из происходящего могу понять, что читать умеет только mickfallout.
1. баблинг происходит не зависимо от того, есть слушатели или нет. 2. когда генерируется событие ему всё равно придётся на каждом этапе всплытия проверить "а есть ли тут слушатель". 3. если у нас будет 500 вложенностей, то произойдёт 500 проверок для события. независимо от того на каком уровне вложенности Вы подпишитесь, все 500 проверок произойдут любом случаи. исходя из этого на скорость обработки это никак не повлияет. подписываясь у родителя, Вы делаете это один раз. создавая всего одного слушателя. подписываясь у каждого из детей, Вы создаёте N слушателей.соответственно вы тратите в N раз больше памяти и в N раз у вас будет медленнее инициализация прослушки. |
имелось в виду 50-500 одноуровневых детей ессно)))
|
orcpochta, да это совершенно не важно, и к теме не относится.
|
как же не относится? дети есть, слушатели есть
|
повторюсь:
Цитата:
|
Цитата:
Затраты на всплытие, проверки наличие листнера будут одинаковы, надеюсь это понятно. отличатся будут только затраты подписки/отписки. при 50 объектах вы 50 раз подпишите каждого ребёнка или один раз - родителя. вне зависимости от того является ли отец "дедом", "прадедом" и т.п. =) |
mickfallout, думаешь с 3го раза станет понятнее? :D
|
BlooDHounD, возможно =) в педагогике вроде считается что повторять надо 3 раза... =)
|
повторение - мать утечения...))
семь раз прочти один раз напиши)) спасибо, вобщем ответили на вопрос и примерно логика ясна |
Только ещё момент есть: например, по клику если подписан лишь родитель, а нужно получить дитё, которое лежит под мышкой нужно провести какие-то операции, например getObjectsUnderPoint, и в итоге мы получаем доп. нагрузку (пусть и мизерную, в другом случае это может быть чуть более существенно) в момент исполнения программы. Затрачивая больше памяти и подписывая все N объектов на клик мы загружаем ЦП единожды, во время подписки, а по клику сразу имеем нужный объект.
Я к тому, что нужно по задаче больше смотреть. Я слабо представляю, но могу допустить ситуацию в котором при каждом движении мыши надо производить какие-то нечеловеческие калькуляции математикой, чтобы узнать кто лежит внизу и тогда, наверное, подписка каждого объекта была бы предпочительней |
stopPropagation наше всё.
|
Цитата:
|
mickfallout, видимо он бредит. просто он ничего не знает о event.target.
|
в target, в currentTarget хранится тот, кого подписали на событие.
Код AS3:
|
Цитата:
|
Я думаю, что не все так однозначно, т.как для проверки необходимости отправки события прийдется затратить больше усилий, елси мы будем делать "точный" хиттест (т.е. с шейп флагами), а, если, например, заранее извесно, что все дети - прямоугольники, то, возможно, что отключив им mouseEnabled, и сделав более простой хиттест, мы получим лучший результат, чем при всплытии... Кроме того, всплывающие события создаются по-новой, таким образом, мы рискуем нарваться на GC во время этого процесса - и, раз на десять весь процесс вцелом будет изза этого гораздо дольше.
|
чего чего про GC? не понял.
|
Создавая новый объект мы рискуем вызвать GC, а он работает достаточно долго. Тем самым мы рискуем в какой-то момент времени сделать очень "дорогое" событие.
|
Psycho Tiger, создавая новый объект мы ничем не рискуем. и пока вызов стэка не завершиться никакой GC ничего убивать не будет. и уж тем более объект, который передаётся в параметре. все события в ФП вызываются синхронно, и вообще не понимаю как GC может вообще возникнуть в такой ситуации. это типа если бы я гулял по центральному парку Нью-Йорка, и тут на меня из-за одинокого дерева БелАЗ выезжает. вероятности приблизительно равны.
|
на сколько я себе представляю модель событий DOM (не на уровне АС3, а на уровне логики ее работы), каждый раз когда возникает событие, диспетчер строит цепочку от корня до цели (последней ветки) и работает только с этой цепочкой. Это подтверждает тот факт, что удаление или добавление слушателя в тот момент, когда событие уже произошло и обрабатывается, не влияет на результат обработки события.
И делаю вывод такой: скорость работы схемы с подпиской слушателя на каждый объект будет такой же, как и с подпиской на родителя. Однако, она будет быстрее, чем если подписывается не родитель, а дед или прадед. |
Цитата:
|
веток больше, проход от корня к цели дольше. чо тут не понятно ?
|
Извиняюсь, что встреваю, но ни у кого нет желания провести парочку тестов? А то я за этой темы слежу с момента ее создания, а времени с того момента прошло уже достаточно, а пока чуть ли не холивар...
Сделал бы и сам, но боюсь что мой код поднимут на смех... |
Цитата:
Короче говоря: Код AS3:
|
Crenth, а Вы о том, что чем ниже к предок тем позже вызовится событие? спасибо, КО. Вы не поверите, но именно в этом суть баблинга. было бы стрёмно, если бы события предков вызывались в вперемешку =) и разница в отклике в пару наносекунд, я думаю никого не волнует.
Psycho Tiger, а зачем Вы там будите вызывать GC? |
| Часовой пояс GMT +4, время: 21:46. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.