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.68 by root, Fri Apr 25 07:14:33 2008 UTC

… …
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 directly, here is a benchmark of various supported
870models natively and with anyevent. The benchmark creates a lot of timers 870event 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 871timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to
872writable), lets them fire exactly once and destroys them again. 872become writable, which it is), lets them fire exactly once and destroys
873them again.
873 874
874Explanation of the fields: 875=head2 Explanation of the fields
875 876
876I<watcher> is the number of event watchers created/destroyed. Sicne 877I<watcher> is the number of event watchers created/destroyed. Since
877different event models have vastly different performance each backend was 878different event models feature vastly different performances, each event
878handed a number of watchers so that overall runtime is acceptable and 879loop was given a number of watchers so that overall runtime is acceptable
879similar to all backends (and keep them from crashing). 880and similar between tested event loop (and keep them from crashing): Glib
881would probably take thousands of years if asked to process the same number
882of watchers as EV in this benchmark.
880 883
881I<bytes> is the number of bytes (as measured by resident set size) used by 884I<bytes> is the number of bytes (as measured by the resident set size,
882each watcher. 885RSS) consumed by each watcher. This method of measuring captures both C
886and Perl-based overheads.
883 887
884I<create> is the time, in microseconds, to create a single watcher. 888I<create> is the time, in microseconds (millionths of seconds), that it
889takes to create a single watcher. The callback is a closure shared between
890all watchers, to avoid adding memory overhead. That means closure creation
891and memory usage is not included in the figures.
885 892
886I<invoke> is the time, in microseconds, used to invoke a simple callback 893I<invoke> is the time, in microseconds, used to invoke a simple
887that simply counts down. 894callback. The callback simply counts down a Perl variable and after it was
895invoked "watcher" times, it would C<< ->broadcast >> a condvar once.
888 896
889I<destroy> is the time, in microseconds, to destroy a single watcher. 897I<destroy> is the time, in microseconds, that it takes destroy a single
898watcher.
899
900=head2 Results
890 901
891 name watcher bytes create invoke destroy comment 902 name watcher bytes create invoke destroy comment
892 EV/EV 400000 244 0.56 0.46 0.31 EV native interface 903 EV/EV 400000 244 0.56 0.46 0.31 EV native interface
893 EV/Any 100000 610 3.52 0.91 0.75 904 EV/Any 100000 610 3.52 0.91 0.75
894 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal 905 CoroEV/Any 100000 610 3.49 0.92 0.75 coroutines + Coro::Signal
… …
898 Glib/Any 16000 1357 96.99 12.55 55.51 quadratic behaviour 909 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 910 Tk/Any 2000 1855 27.01 66.61 14.03 SEGV with >> 2000 watchers
900 POE/Select 2000 6343 94.69 807.65 562.69 POE::Loop::Select 911 POE/Select 2000 6343 94.69 807.65 562.69 POE::Loop::Select
901 POE/Event 2000 6644 108.15 768.19 14.33 POE::Loop::Event 912 POE/Event 2000 6644 108.15 768.19 14.33 POE::Loop::Event
902 913
903Discussion: The benchmark does I<not> bench scalability of the 914=head2 Discussion
915
916The benchmark does I<not> measure scalability of the event loop very
904backend. For example a select-based backend (such as the pureperl one) can 917well. 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 918can never compete with an event loop that uses epoll when the number of
906filehandle is used. 919file descriptors grows high. In this benchmark, only a single filehandle
920is used (although some of the AnyEvent adaptors dup() its file descriptor
921to worka round bugs).
907 922
908EV is the sole leader regarding speed and memory use, which are both 923C<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 924maximal/minimal, respectively. Even when going through AnyEvent, there is
910loop that uses less memory (the Event module natively), and no faster 925only one event loop that uses less memory (the C<Event> module natively), and
911event model. 926no faster event model, not event C<Event> natively.
912 927
913The pure perl implementation is hit in a few sweet spots (both the 928The 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 929zero 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 930interpreter and the backend itself). Nevertheless tis shows that it
916overhead in itself. Like any select-based backend it's performance becomes 931adds very little overhead in itself. Like any select-based backend its
917really bad with lots of file descriptors. 932performance becomes really bad with lots of file descriptors, of course,
933but this was not subjetc of this benchmark.
918 934
919The Event module has a relatively high setup and callback invocation cost, 935The C<Event> module has a relatively high setup and callback invocation cost,
920but overall scores on the third place. 936but overall scores on the third place.
921 937
922Glib has a little higher memory cost, a bit fster callback invocation and 938C<Glib>'s memory usage is quite a bit bit higher, features a faster
923has a similar speed as Event. 939callback invocation and overall lands in the same class as C<Event>.
924 940
925The Tk backend works relatively well, the fact that it crashes with 941The C<Tk> adaptor works relatively well, the fact that it crashes with
926more than 2000 watchers is a big setback, however, as correctness takes 942more than 2000 watchers is a big setback, however, as correctness takes
927precedence over speed. 943precedence over speed. Nevertheless, its performance is surprising, as the
944file descriptor is dup()ed for each watcher. This shows that the dup()
945employed by some adaptors is not a big performance issue (it does incur a
946hidden memory cost inside the kernel, though).
928 947
929POE, regardless of backend (wether it's pure perl select backend or the 948C<POE>, regardless of backend (wether using its pure perl select-based
930Event backend) shows abysmal performance and memory usage: Watchers use 949backend or the Event backend) shows abysmal performance and memory
931almost 30 times as much memory as EV watchers, and 10 times as much memory 950usage: Watchers use almost 30 times as much memory as EV watchers, and 10
932as both Event or EV via AnyEvent. 951times as much memory as both Event or EV via AnyEvent. Watcher invocation
952is almost 700 times slower as with AnyEvent's pure perl implementation.
933 953
934Summary: using EV through AnyEvent is faster than any other event 954Summary: using EV through AnyEvent is faster than any other event
935loop. The overhead AnyEvent adds can be very small, and you should avoid 955loop. The overhead AnyEvent adds can be very small, and you should avoid
936POE like the plague if you want performance or reasonable memory usage. 956POE like the plague if you want performance or reasonable memory usage.
937 957

Diff Legend

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