… | |
… | |
434 | no warnings; |
434 | no warnings; |
435 | use strict; |
435 | use strict; |
436 | |
436 | |
437 | use Carp; |
437 | use Carp; |
438 | |
438 | |
439 | our $VERSION = '3.2'; |
439 | our $VERSION = '3.3'; |
440 | our $MODEL; |
440 | our $MODEL; |
441 | |
441 | |
442 | our $AUTOLOAD; |
442 | our $AUTOLOAD; |
443 | our @ISA; |
443 | our @ISA; |
444 | |
444 | |
… | |
… | |
860 | $quit->broadcast; |
860 | $quit->broadcast; |
861 | }); |
861 | }); |
862 | |
862 | |
863 | $quit->wait; |
863 | $quit->wait; |
864 | |
864 | |
|
|
865 | |
|
|
866 | =head1 BENCHMARK |
|
|
867 | |
|
|
868 | To give you an idea of the performance and overheads that AnyEvent adds |
|
|
869 | over the event loops directly, here is a benchmark of various supported |
|
|
870 | event models natively and with anyevent. The benchmark creates a lot of |
|
|
871 | timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to |
|
|
872 | become writable, which it is), lets them fire exactly once and destroys |
|
|
873 | them again. |
|
|
874 | |
|
|
875 | =head2 Explanation of the columns |
|
|
876 | |
|
|
877 | I<watcher> is the number of event watchers created/destroyed. Since |
|
|
878 | different event models feature vastly different performances, each event |
|
|
879 | loop was given a number of watchers so that overall runtime is acceptable |
|
|
880 | and similar between tested event loop (and keep them from crashing): Glib |
|
|
881 | would probably take thousands of years if asked to process the same number |
|
|
882 | of watchers as EV in this benchmark. |
|
|
883 | |
|
|
884 | I<bytes> is the number of bytes (as measured by the resident set size, |
|
|
885 | RSS) consumed by each watcher. This method of measuring captures both C |
|
|
886 | and Perl-based overheads. |
|
|
887 | |
|
|
888 | I<create> is the time, in microseconds (millionths of seconds), that it |
|
|
889 | takes to create a single watcher. The callback is a closure shared between |
|
|
890 | all watchers, to avoid adding memory overhead. That means closure creation |
|
|
891 | and memory usage is not included in the figures. |
|
|
892 | |
|
|
893 | I<invoke> is the time, in microseconds, used to invoke a simple |
|
|
894 | callback. The callback simply counts down a Perl variable and after it was |
|
|
895 | invoked "watcher" times, it would C<< ->broadcast >> a condvar once to |
|
|
896 | signal the end of this phase. |
|
|
897 | |
|
|
898 | I<destroy> is the time, in microseconds, that it takes destroy a single |
|
|
899 | watcher. |
|
|
900 | |
|
|
901 | =head2 Results |
|
|
902 | |
|
|
903 | name watcher bytes create invoke destroy comment |
|
|
904 | EV/EV 400000 244 0.56 0.46 0.31 EV native interface |
|
|
905 | EV/Any 100000 610 3.52 0.91 0.75 |
|
|
906 | CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal |
|
|
907 | Perl/Any 10000 654 4.64 1.22 0.77 pure perl implementation |
|
|
908 | Event/Event 10000 523 28.05 21.38 5.22 Event native interface |
|
|
909 | Event/Any 10000 943 34.43 20.48 1.39 |
|
|
910 | Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour |
|
|
911 | Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers |
|
|
912 | POE/Select 2000 6343 94.69 807.65 562.69 POE::Loop::Select |
|
|
913 | POE/Event 2000 6644 108.15 768.19 14.33 POE::Loop::Event |
|
|
914 | |
|
|
915 | =head2 Discussion |
|
|
916 | |
|
|
917 | The benchmark does I<not> measure scalability of the event loop very |
|
|
918 | well. For example, a select-based event loop (such as the pure perl one) |
|
|
919 | can never compete with an event loop that uses epoll when the number of |
|
|
920 | file descriptors grows high. In this benchmark, only a single filehandle |
|
|
921 | is used (although some of the AnyEvent adaptors dup() its file descriptor |
|
|
922 | to worka round bugs). |
|
|
923 | |
|
|
924 | C<EV> is the sole leader regarding speed and memory use, which are both |
|
|
925 | maximal/minimal, respectively. Even when going through AnyEvent, there is |
|
|
926 | only one event loop that uses less memory (the C<Event> module natively), and |
|
|
927 | no faster event model, not event C<Event> natively. |
|
|
928 | |
|
|
929 | The pure perl implementation is hit in a few sweet spots (both the |
|
|
930 | zero timeout and the use of a single fd hit optimisations in the perl |
|
|
931 | interpreter and the backend itself). Nevertheless tis shows that it |
|
|
932 | adds very little overhead in itself. Like any select-based backend its |
|
|
933 | performance becomes really bad with lots of file descriptors, of course, |
|
|
934 | but this was not subjetc of this benchmark. |
|
|
935 | |
|
|
936 | The C<Event> module has a relatively high setup and callback invocation cost, |
|
|
937 | but overall scores on the third place. |
|
|
938 | |
|
|
939 | C<Glib>'s memory usage is quite a bit bit higher, features a faster |
|
|
940 | callback invocation and overall lands in the same class as C<Event>. |
|
|
941 | |
|
|
942 | The C<Tk> adaptor works relatively well, the fact that it crashes with |
|
|
943 | more than 2000 watchers is a big setback, however, as correctness takes |
|
|
944 | precedence over speed. Nevertheless, its performance is surprising, as the |
|
|
945 | file descriptor is dup()ed for each watcher. This shows that the dup() |
|
|
946 | employed by some adaptors is not a big performance issue (it does incur a |
|
|
947 | hidden memory cost inside the kernel, though). |
|
|
948 | |
|
|
949 | C<POE>, regardless of backend (wether using its pure perl select-based |
|
|
950 | backend or the Event backend) shows abysmal performance and memory |
|
|
951 | usage: Watchers use almost 30 times as much memory as EV watchers, and 10 |
|
|
952 | times as much memory as both Event or EV via AnyEvent. Watcher invocation |
|
|
953 | is almost 700 times slower as with AnyEvent's pure perl implementation. |
|
|
954 | |
|
|
955 | Summary: using EV through AnyEvent is faster than any other event |
|
|
956 | loop. The overhead AnyEvent adds can be very small, and you should avoid |
|
|
957 | POE like the plague if you want performance or reasonable memory usage. |
|
|
958 | |
|
|
959 | |
865 | =head1 FORK |
960 | =head1 FORK |
866 | |
961 | |
867 | Most event libraries are not fork-safe. The ones who are usually are |
962 | Most event libraries are not fork-safe. The ones who are usually are |
868 | because they are so inefficient. Only L<EV> is fully fork-aware. |
963 | because they are so inefficient. Only L<EV> is fully fork-aware. |
869 | |
964 | |
870 | If you have to fork, you must either do so I<before> creating your first |
965 | If you have to fork, you must either do so I<before> creating your first |
871 | watcher OR you must not use AnyEvent at all in the child. |
966 | watcher OR you must not use AnyEvent at all in the child. |
|
|
967 | |
872 | |
968 | |
873 | =head1 SECURITY CONSIDERATIONS |
969 | =head1 SECURITY CONSIDERATIONS |
874 | |
970 | |
875 | AnyEvent can be forced to load any event model via |
971 | AnyEvent can be forced to load any event model via |
876 | $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to |
972 | $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used to |
… | |
… | |
884 | |
980 | |
885 | BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } |
981 | BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } |
886 | |
982 | |
887 | use AnyEvent; |
983 | use AnyEvent; |
888 | |
984 | |
|
|
985 | |
889 | =head1 SEE ALSO |
986 | =head1 SEE ALSO |
890 | |
987 | |
891 | Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>, |
988 | Event modules: L<Coro::EV>, L<EV>, L<EV::Glib>, L<Glib::EV>, |
892 | L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>, |
989 | L<Coro::Event>, L<Event>, L<Glib::Event>, L<Glib>, L<Coro>, L<Tk>, |
893 | L<Event::Lib>, L<Qt>, L<POE>. |
990 | L<Event::Lib>, L<Qt>, L<POE>. |
… | |
… | |
897 | L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>, |
994 | L<AnyEvent::Impl::Tk>, L<AnyEvent::Impl::Perl>, L<AnyEvent::Impl::EventLib>, |
898 | L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>. |
995 | L<AnyEvent::Impl::Qt>, L<AnyEvent::Impl::POE>. |
899 | |
996 | |
900 | Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>. |
997 | Nontrivial usage examples: L<Net::FCP>, L<Net::XMPP2>. |
901 | |
998 | |
|
|
999 | |
902 | =head1 AUTHOR |
1000 | =head1 AUTHOR |
903 | |
1001 | |
904 | Marc Lehmann <schmorp@schmorp.de> |
1002 | Marc Lehmann <schmorp@schmorp.de> |
905 | http://home.schmorp.de/ |
1003 | http://home.schmorp.de/ |
906 | |
1004 | |