ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent/lib/AnyEvent.pm
(Generate patch)

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.65 by root, Fri Apr 25 06:58:12 2008 UTC vs.
Revision 1.78 by root, Fri Apr 25 09:06:27 2008 UTC

… …
136 136
137Note that C<my $w; $w => combination. This is necessary because in Perl, 137Note that C<my $w; $w => combination. This is necessary because in Perl,
138my variables are only visible after the statement in which they are 138my variables are only visible after the statement in which they are
139declared. 139declared.
140 140
141=head2 IO WATCHERS 141=head2 I/O WATCHERS
142 142
143You can create an I/O watcher by calling the C<< AnyEvent->io >> method 143You can create an I/O watcher by calling the C<< AnyEvent->io >> method
144with the following mandatory key-value pairs as arguments: 144with the following mandatory key-value pairs as arguments:
145 145
146C<fh> the Perl I<file handle> (I<not> file descriptor) to watch for 146C<fh> the Perl I<file handle> (I<not> file descriptor) to watch for
… …
706 706
707=back 707=back
708 708
709=head1 EXAMPLE PROGRAM 709=head1 EXAMPLE PROGRAM
710 710
711The following program uses an IO watcher to read data from STDIN, a timer 711The following program uses an I/O watcher to read data from STDIN, a timer
712to display a message once per second, and a condition variable to quit the 712to display a message once per second, and a condition variable to quit the
713program when the user enters quit: 713program when the user enters quit:
714 714
715 use AnyEvent; 715 use AnyEvent;
716 716
… …
864 864
865 865
866=head1 BENCHMARK 866=head1 BENCHMARK
867 867
868To give you an idea of the performance and overheads that AnyEvent adds 868To give you an idea of the performance and overheads that AnyEvent adds
869over the backends directly, here is a benchmark of various supported event 869over the event loops themselves (and to give you an impression of the
870speed of various event loops), here is a benchmark of various supported
870models natively and with anyevent. The benchmark creates a lot of timers 871event models natively and with anyevent. The benchmark creates a lot of
871(with a zero timeout) and io events (watching STDOUT, a pty, to become 872timers (with a zero timeout) and I/O watchers (watching STDOUT, a pty, to
872writable), lets them fire exactly once and destroys them again. 873become writable, which it is), lets them fire exactly once and destroys
874them again.
873 875
874Explanation of the fields: 876Rewriting the benchmark to use many different sockets instead of using
877the same filehandle for all I/O watchers results in a much longer runtime
878(socket creation is expensive), but qualitatively the same figures, so it
879was not used.
875 880
881=head2 Explanation of the columns
882
876I<watcher> is the number of event watchers created/destroyed. Sicne 883I<watcher> is the number of event watchers created/destroyed. Since
877different event models have vastly different performance each backend was 884different event models feature vastly different performances, each event
878handed a number of watchers so that overall runtime is acceptable and 885loop was given a number of watchers so that overall runtime is acceptable
879similar to all backends (and keep them from crashing). 886and similar between tested event loop (and keep them from crashing): Glib
887would probably take thousands of years if asked to process the same number
888of watchers as EV in this benchmark.
880 889
881I<bytes> is the number of bytes (as measured by resident set size) used by 890I<bytes> is the number of bytes (as measured by the resident set size,
882each watcher. 891RSS) consumed by each watcher. This method of measuring captures both C
892and Perl-based overheads.
883 893
884I<create> is the time, in microseconds, to create a single watcher. 894I<create> is the time, in microseconds (millionths of seconds), that it
895takes to create a single watcher. The callback is a closure shared between
896all watchers, to avoid adding memory overhead. That means closure creation
897and memory usage is not included in the figures.
885 898
886I<invoke> is the time, in microseconds, used to invoke a simple callback 899I<invoke> is the time, in microseconds, used to invoke a simple
887that simply counts down. 900callback. The callback simply counts down a Perl variable and after it was
901invoked "watcher" times, it would C<< ->broadcast >> a condvar once to
902signal the end of this phase.
888 903
889I<destroy> is the time, in microseconds, to destroy a single watcher. 904I<destroy> is the time, in microseconds, that it takes to destroy a single
905watcher.
890 906
907=head2 Results
908
891 name watcher bytes create invoke destroy comment 909 name watchers bytes create invoke destroy comment
892 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 910 EV/EV 400000 244 0.56 0.46 0.31 EV native interface
893 EV/Any 100000 610 3.52 0.91 0.75 911 EV/Any 100000 610 3.52 0.91 0.75 EV + AnyEvent watchers
894 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal 912 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal
895 Perl/Any 10000 654 4.64 1.22 0.77 pure perl implementation 913 Perl/Any 100000 513 4.91 0.92 1.15 pure perl implementation
896 Event/Event 10000 523 28.05 21.38 5.22 Event native interface 914 Event/Event 16000 523 28.05 21.38 0.86 Event native interface
897 Event/Any 10000 943 34.43 20.48 1.39 915 Event/Any 16000 943 34.43 20.48 1.39 Event + AnyEvent watchers
898 Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour 916 Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour
899 Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers 917 Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers
918 POE/Event 2000 6644 108.15 768.19 14.33 via POE::Loop::Event
900 POE/Select 2000 6343 94.69 807.65 562.69 POE::Loop::Select 919 POE/Select 2000 6343 94.69 807.65 562.69 via POE::Loop::Select
901 POE/Event 2000 6644 108.15 768.19 14.33 POE::Loop::Event
902 920
903Discussion: The benchmark does I<not> bench scalability of the 921=head2 Discussion
922
923The benchmark does I<not> measure scalability of the event loop very
904backend. For example a select-based backend (such as the pureperl one) can 924well. For example, a select-based event loop (such as the pure perl one)
905never compete with a backend using epoll. In this benchmark, only a single 925can never compete with an event loop that uses epoll when the number of
906filehandle is used. 926file descriptors grows high. In this benchmark, only a single filehandle
927is used (although some of the AnyEvent adaptors dup() its file descriptor
928to worka round bugs).
907 929
908EV is the sole leader regarding speed and memory use, which are both 930C<EV> is the sole leader regarding speed and memory use, which are both
909maximal/minimal. Even when going through AnyEvent, there is only one event 931maximal/minimal, respectively. Even when going through AnyEvent, there are
910loop that uses less memory (the Event module natively), and no faster 932only two event loops that use slightly less memory (the C<Event> module
911event model. 933natively and the pure perl backend), and no faster event models, not even
934C<Event> natively.
912 935
913The pure perl implementation is hit in a few sweet spots (both the 936The pure perl implementation is hit in a few sweet spots (both the
914zero timeout and the use of a single fd hit optimisations in the perl 937zero timeout and the use of a single fd hit optimisations in the perl
915interpreter and the backend itself), but it shows that it adds very little 938interpreter and the backend itself, and all watchers become ready at the
939same time). Nevertheless this shows that it adds very little overhead in
916overhead in itself. Like any select-based backend it's performance becomes 940itself. Like any select-based backend its performance becomes really bad
917really bad with lots of file descriptors. 941with lots of file descriptors (and few of them active), of course, but
942this was not subject of this benchmark.
918 943
919The Event module has a relatively high setup and callback invocation cost, 944The C<Event> module has a relatively high setup and callback invocation cost,
920but overall scores on the third place. 945but overall scores on the third place.
921 946
922Glib has a little higher memory cost, a bit fster callback invocation and 947C<Glib>'s memory usage is quite a bit bit higher, but it features a
923has a similar speed as Event. 948faster callback invocation and overall ends up in the same class as
949C<Event>. However, Glib scales extremely badly, doubling the number of
950watchers increases the processing time by more than a factor of four,
951making it completely unusable when using larger numbers of watchers
952(note that only a single file descriptor was used in the benchmark, so
953inefficiencies of C<poll> do not account for this).
924 954
925The Tk backend works relatively well, the fact that it crashes with 955The C<Tk> adaptor works relatively well. The fact that it crashes with
926more than 2000 watchers is a big setback, however, as correctness takes 956more than 2000 watchers is a big setback, however, as correctness takes
927precedence over speed. 957precedence over speed. Nevertheless, its performance is surprising, as the
958file descriptor is dup()ed for each watcher. This shows that the dup()
959employed by some adaptors is not a big performance issue (it does incur a
960hidden memory cost inside the kernel, though, that is not reflected in the
961figures above).
928 962
929POE, regardless of backend (wether it's pure perl select backend or the 963C<POE>, regardless of underlying event loop (wether using its pure perl
930Event backend) shows abysmal performance and memory usage: Watchers use 964select-based backend or the Event module) shows abysmal performance and
931almost 30 times as much memory as EV watchers, and 10 times as much memory 965memory usage: Watchers use almost 30 times as much memory as EV watchers,
932as both Event or EV via AnyEvent. 966and 10 times as much memory as both Event or EV via AnyEvent. Watcher
967invocation is almost 700 times slower than with AnyEvent's pure perl
968implementation. The design of the POE adaptor class in AnyEvent can not
969really account for this, as session creation overhead is small compared
970to execution of the state machine, which is coded pretty optimally within
971L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
933 972
973=head2 Summary
974
934Summary: using EV through AnyEvent is faster than any other event 975Using EV through AnyEvent is faster than any other event loop, but most
935loop. The overhead AnyEvent adds can be very small, and you should avoid 976event loops have acceptable performance with or without AnyEvent.
936POE like the plague if you want performance or reasonable memory usage. 977
978The overhead AnyEvent adds is usually much smaller than the overhead of
979the actual event loop, only with extremely fast event loops such as the EV
980adds AnyEvent significant overhead.
981
982And you should simply avoid POE like the plague if you want performance or
983reasonable memory usage.
937 984
938 985
939=head1 FORK 986=head1 FORK
940 987
941Most event libraries are not fork-safe. The ones who are usually are 988Most event libraries are not fork-safe. The ones who are usually are

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines