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