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.70 by root, Fri Apr 25 07:25:44 2008 UTC vs.
Revision 1.73 by root, Fri Apr 25 07:47:12 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 event loops themselves (and to give you an impression of the
869over the event loops directly, here is a benchmark of various supported 870speed of various event loops), here is a benchmark of various supported
870event models natively and with anyevent. The benchmark creates a lot of 871event models natively and with anyevent. The benchmark creates a lot of
871timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to 872timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to
872become writable, which it is), lets them fire exactly once and destroys 873become writable, which it is), lets them fire exactly once and destroys
873them again. 874them again.
874 875
… …
893I<invoke> is the time, in microseconds, used to invoke a simple 894I<invoke> is the time, in microseconds, used to invoke a simple
894callback. The callback simply counts down a Perl variable and after it was 895callback. The callback simply counts down a Perl variable and after it was
895invoked "watcher" times, it would C<< ->broadcast >> a condvar once to 896invoked "watcher" times, it would C<< ->broadcast >> a condvar once to
896signal the end of this phase. 897signal the end of this phase.
897 898
898I<destroy> is the time, in microseconds, that it takes destroy a single 899I<destroy> is the time, in microseconds, that it takes to destroy a single
899watcher. 900watcher.
900 901
901=head2 Results 902=head2 Results
902 903
903 name watcher bytes create invoke destroy comment 904 name watcher bytes create invoke destroy comment
… …
934but this was not subjetc of this benchmark. 935but this was not subjetc of this benchmark.
935 936
936The C<Event> module has a relatively high setup and callback invocation cost, 937The C<Event> module has a relatively high setup and callback invocation cost,
937but overall scores on the third place. 938but overall scores on the third place.
938 939
939C<Glib>'s memory usage is quite a bit bit higher, features a faster 940C<Glib>'s memory usage is quite a bit bit higher, but it features a
940callback invocation and overall lands in the same class as C<Event>. 941faster callback invocation and overall ends up in the same class as
942C<Event>. However, Glib scales extremely badly, doubling the number of
943watchers increases the processing time by more than a factor of four,
944making it completely unusable when using larger numbers of watchers
945(note that only a single file descriptor was used in the benchmark, so
946inefficiencies of C<poll> do not account for this).
941 947
942The C<Tk> adaptor works relatively well, the fact that it crashes with 948The C<Tk> adaptor works relatively well. The fact that it crashes with
943more than 2000 watchers is a big setback, however, as correctness takes 949more than 2000 watchers is a big setback, however, as correctness takes
944precedence over speed. Nevertheless, its performance is surprising, as the 950precedence over speed. Nevertheless, its performance is surprising, as the
945file descriptor is dup()ed for each watcher. This shows that the dup() 951file descriptor is dup()ed for each watcher. This shows that the dup()
946employed by some adaptors is not a big performance issue (it does incur a 952employed by some adaptors is not a big performance issue (it does incur a
947hidden memory cost inside the kernel, though). 953hidden memory cost inside the kernel, though).
948 954
949C<POE>, regardless of backend (wether using its pure perl select-based 955C<POE>, regardless of underlying event loop (wether using its pure perl
950backend or the Event backend) shows abysmal performance and memory 956select-based backend or the Event module) shows abysmal performance and
951usage: Watchers use almost 30 times as much memory as EV watchers, and 10 957memory usage: Watchers use almost 30 times as much memory as EV watchers,
952times as much memory as both Event or EV via AnyEvent. Watcher invocation 958and 10 times as much memory as both Event or EV via AnyEvent. Watcher
953is almost 700 times slower as with AnyEvent's pure perl implementation. 959invocation is almost 700 times slower than with AnyEvent's pure perl
960implementation. The design of the POE adaptor class in AnyEvent can not
961really account for this, as session creation overhead is small compared
962to execution of the state machine, which is coded pretty optimally within
963L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
954 964
965=head2 Summary
966
955Summary: using EV through AnyEvent is faster than any other event 967Using EV through AnyEvent is faster than any other event loop, but most
956loop. The overhead AnyEvent adds can be very small, and you should avoid 968event loops have acceptable performance with or without AnyEvent.
957POE like the plague if you want performance or reasonable memory usage. 969
970The overhead AnyEvent adds is usually much smaller than the overhead of
971the actual event loop, only with extremely fast event loops such as the EV
972adds AnyEvent significant overhead.
973
974And you should simply avoid POE like the plague if you want performance or
975reasonable memory usage.
958 976
959 977
960=head1 FORK 978=head1 FORK
961 979
962Most event libraries are not fork-safe. The ones who are usually are 980Most event libraries are not fork-safe. The ones who are usually are

Diff Legend

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