Pull to refresh

Comments 18

Бред. Сигналы гораздо быстрее, чем события. В этом и плюс. События во флэше вообще ужасно медленная штука, но частенько без баблинга очень грустно.
Согласен. По идее сигналы должны быть быстрее, так как нет сравнения строк, но, походу, так как либа не нативная — работает медленнее, чем EventDispatcher, который вшит в плеер. Если результаты тестирования вызывают сомнения — проверь сам.

У GenericEvent есть параметр bubbles, если выставить в true — будет баблинг работать. Но это только для DeluxeSignal.
Так может все-таки тесты какие-нить? Потому что на первый взгляд менять нативную систему на не нечто не хочется.
UFO just landed and posted this here
Плюсы сигналов в том, что не нужно создавать отдельных классов ивентов и прописывать методы clone для них. просто объявляешь:
var signalProcessComplete:Signal = new Signal(int, String, MyType)
и можешь сразу этот сигнал использовать. получается очень компактно, быстро и без «бойлеров» :)
UFO just landed and posted this here
Ну, продолжайте бойлерить, если есть время :)
UFO just landed and posted this here
Ага, давайте начнем холивар, по поводу в какой IDE удобнее генерировать бойлерплейт :)
Для меня звучит не убедительно. С одной стороны, подписка на события — это не такая уж и большая часть кода, чтобы за её счёт уменьшать объём кода. С другой, для приложений выкладываемых в сеть производительность очень важна, т.к. им могут воспользоваться люди со слабыми ПК.
Что хотелось бы увидеть:
1. Если объём кода уменьшается, то насколько? Например, применил сигналы в этом проекте — объём кода уменьшился на 5%.
2. Рассказали бы, какие решения можно перенести с C# в ActionScript. И почему их нельзя или неудобно использовать без сигналов.
Интересно, что вот тут:
alecmce.com/as3/events-and-signals-performance-tests
приходят к противоположным выводам насчет скорости. Сигналы быстрее

Есть еще одно важное дополнение. Вот тут:
knowledge.robotlegs.org/discussions/questions/351-signals-vs-events-whats-better
в комментариях пишут:
Сигналы диспетчатся в текущем фрейме. Про event нельзя однозначно сказать в каком фрейме вы получите вызов обработчика. Возможно в текущем, возможно в следующем, смотря как решит флешплеер. Где-то мне еще аналогичные сравнения попадались.

Использовал библиотеку сигналов в одном проекте: www.rndgames.com/multiplayer/checkers/
В общем вполне доволен, буду еще использовать :)
>Интересно, что вот тут:
>alecmce.com/as3/events-and-signals-performance-tests
>приходят к противоположным выводам насчет скорости. Сигналы быстрее


А какого фига они тестируют без навешенных листенеров? :)
samoiloff.com/tmp/Main.as — вот их класс, добавил только тайминги на тесты, ну никак не получаются сигналы быстрее диспатчера. (Время на 100 000 лупов в миллисекундах).

Main.Main(); event: 250
Main.Main(); signal: 377

Может я что-то делаю не так? Тестировал правда на на win7.
Откомпилировал этот файл.
вот результаты дебаг-плеера:
[Starting debug session with FDB]
Main.Main(); event: 145
Main.Main(); signal: 148

А вот результаты release-плеера:
event :107
signal 77
(вывел в TextField, т.к. у меня FlashDevelop не отлавливает трейсы релизной версии)

p.s. компьютер: i3, 2gb
прилинкована: as3-signals-v0.7.swc
кстати да, релиз не тестил, может проблема в этом, спасибо
Вообще-то во Flash не имеет смысла тестить в debug — есть множество операций, которые в релизе быстрее, а в дебаге медленнее своих аналогов.
Если взять не simpleSignal и simpleEvent, а dataEvent и dataSignal, то на Windows 7, FP 10.1 картина меняется (указано среднее округлённое время в 5 повторах):

Main.Main(); event: 182
Main.Main(); signal: 186

Один раз из пяти повторов было, что сигналы быстрее событий:

Main.Main(); event: 189
Main.Main(); signal: 186

Использовал версию as3-signals-v0.8 и релиз.
Sign up to leave a comment.

Articles