[ViewVC] Diff of: cvs/AnyEvent/lib/AnyEvent.pm

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.92 by root, Sat Apr 26 04:19:02 2008 UTC vs.
Revision 1.104 by root, Wed Apr 30 11:40:22 2008 UTC

 technically possible.
 Of course, if you want lots of policy (this can arguably be somewhat
 useful) and you want to force your users to use the one and only event
 model, you should I<not> use this module.
 =head1 DESCRIPTION
 L<AnyEvent> provides an identical interface to multiple event loops. This
 allows module authors to utilise an event loop without forcing module
    AnyEvent::Impl::CoroEV    based on Coro::EV, best choice.
    AnyEvent::Impl::CoroEvent based on Coro::Event, second best choice.
    AnyEvent::Impl::EV        based on EV (an interface to libev, best choice).
    AnyEvent::Impl::Event     based on Event, second best choice.
+   AnyEvent::Impl::Perl      pure-perl implementation, fast and portable.
    AnyEvent::Impl::Glib      based on Glib, third-best choice.
-   AnyEvent::Impl::Perl      pure-perl implementation, inefficient but portable.
    AnyEvent::Impl::Tk        based on Tk, very bad choice.
    AnyEvent::Impl::Qt        based on Qt, cannot be autoprobed (see its docs).
    AnyEvent::Impl::EventLib  based on Event::Lib, leaks memory and worse.
    AnyEvent::Impl::POE       based on POE, not generic enough for full support.
 You can chose to use a rather inefficient pure-perl implementation by
 loading the C<AnyEvent::Impl::Perl> module, which gives you similar
 behaviour everywhere, but letting AnyEvent chose is generally better.
+=head1 OTHER MODULES
+The following is a non-exhaustive list of additional modules that use
+AnyEvent and can therefore be mixed easily with other AnyEvent modules
+in the same program. Some of the modules come with AnyEvent, some are
+available via CPAN.
+=over 4
+=item L<AnyEvent::Util>
+Contains various utility functions that replace often-used but blocking
+functions such as C<inet_aton> by event-/callback-based versions.
+=item L<AnyEvent::Handle>
+Provide read and write buffers and manages watchers for reads and writes.
+=item L<AnyEvent::Socket>
+Provides a means to do non-blocking connects, accepts etc.
+=item L<AnyEvent::HTTPD>
+Provides a simple web application server framework.
+=item L<AnyEvent::DNS>
+Provides asynchronous DNS resolver capabilities, beyond what
+L<AnyEvent::Util> offers.
+=item L<AnyEvent::FastPing>
+The fastest ping in the west.
+=item L<Net::IRC3>
+AnyEvent based IRC client module family.
+=item L<Net::XMPP2>
+AnyEvent based XMPP (Jabber protocol) module family.
+=item L<Net::FCP>
+AnyEvent-based implementation of the Freenet Client Protocol, birthplace
+of AnyEvent.
+=item L<Event::ExecFlow>
+High level API for event-based execution flow control.
+=item L<Coro>
+Has special support for AnyEvent.
+=item L<IO::Lambda>
+The lambda approach to I/O - don't ask, look there. Can use AnyEvent.
+=item L<IO::AIO>
+Truly asynchronous I/O, should be in the toolbox of every event
+programmer. Can be trivially made to use AnyEvent.
+=item L<BDB>
+Truly asynchronous Berkeley DB access. Can be trivially made to use
+AnyEvent.
+=back
 =cut
 package AnyEvent;
 no warnings;
 my @models = (
    [Coro::EV::             => AnyEvent::Impl::CoroEV::],
    [Coro::Event::          => AnyEvent::Impl::CoroEvent::],
    [EV::                   => AnyEvent::Impl::EV::],
    [Event::                => AnyEvent::Impl::Event::],
-   [Glib::                 => AnyEvent::Impl::Glib::],
    [Tk::                   => AnyEvent::Impl::Tk::],
    [Wx::                   => AnyEvent::Impl::POE::],
    [Prima::                => AnyEvent::Impl::POE::],
    [AnyEvent::Impl::Perl:: => AnyEvent::Impl::Perl::],
    # everything below here will not be autoprobed as the pureperl backend should work everywhere
+   [Glib::                 => AnyEvent::Impl::Glib::],
    [Event::Lib::           => AnyEvent::Impl::EventLib::], # too buggy
    [Qt::                   => AnyEvent::Impl::Qt::],       # requires special main program
    [POE::Kernel::          => AnyEvent::Impl::POE::],      # lasciate ogni speranza
 );
          EV/EV   400000   244   0.56   0.46    0.31 EV native interface
         EV/Any   100000   244   2.50   0.46    0.29 EV + AnyEvent watchers
     CoroEV/Any   100000   244   2.49   0.44    0.29 coroutines + Coro::Signal
       Perl/Any   100000   513   4.92   0.87    1.12 pure perl implementation
    Event/Event    16000   516  31.88  31.30    0.85 Event native interface
-     Event/Any    16000   936  39.17  33.63    1.43 Event + AnyEvent watchers
+     Event/Any    16000   590  35.75  31.42    1.08 Event + AnyEvent watchers
       Glib/Any    16000  1357  98.22  12.41   54.00 quadratic behaviour
         Tk/Any     2000  1860  26.97  67.98   14.00 SEGV with >> 2000 watchers
      POE/Event     2000  6644 108.64 736.02   14.73 via POE::Loop::Event
     POE/Select     2000  6343  94.13 809.12  565.96 via POE::Loop::Select
 well. For example, a select-based event loop (such as the pure perl one)
 can never compete with an event loop that uses epoll when the number of
 file descriptors grows high. In this benchmark, all events become ready at
 the same time, so select/poll-based implementations get an unnatural speed
 boost.
+Also, note that the number of watchers usually has a nonlinear effect on
+overall speed, that is, creating twice as many watchers doesn't take twice
+the time - usually it takes longer. This puts event loops tested with a
+higher number of watchers at a disadvantage.
+To put the range of results into perspective, consider that on the
+benchmark machine, handling an event takes roughly 1600 CPU cycles with
+EV, 3100 CPU cycles with AnyEvent's pure perl loop and almost 3000000 CPU
+cycles with POE.
 C<EV> is the sole leader regarding speed and memory use, which are both
 maximal/minimal, respectively. Even when going through AnyEvent, it uses
 far less memory than any other event loop and is still faster than Event
 natively.
 file descriptor is dup()ed for each watcher. This shows that the dup()
 employed by some adaptors is not a big performance issue (it does incur a
 hidden memory cost inside the kernel which is not reflected in the figures
 above).
-C<POE>, regardless of underlying event loop (whether using its pure
+C<POE>, regardless of underlying event loop (whether using its pure perl
-perl select-based backend or the Event module, the POE-EV backend
+select-based backend or the Event module, the POE-EV backend couldn't
-couldn't be tested because it wasn't working) shows abysmal performance
+be tested because it wasn't working) shows abysmal performance and
-and memory usage: Watchers use almost 30 times as much memory as
+memory usage with AnyEvent: Watchers use almost 30 times as much memory
-EV watchers, and 10 times as much memory as Event (the high memory
+as EV watchers, and 10 times as much memory as Event (the high memory
 requirements are caused by requiring a session for each watcher). Watcher
 invocation speed is almost 900 times slower than with AnyEvent's pure perl
+implementation.
-implementation. The design of the POE adaptor class in AnyEvent can not
+The design of the POE adaptor class in AnyEvent can not really account
-really account for this, as session creation overhead is small compared
+for the performance issues, though, as session creation overhead is
-to execution of the state machine, which is coded pretty optimally within
+small compared to execution of the state machine, which is coded pretty
-L<AnyEvent::Impl::POE>. POE simply seems to be abysmally slow.
+optimally within L<AnyEvent::Impl::POE> (and while everybody agrees that
+using multiple sessions is not a good approach, especially regarding
+memory usage, even the author of POE could not come up with a faster
+design).
 =head3 Summary
 =over 4
 distribution.
 =head3 Explanation of the columns
 I<sockets> is the number of sockets, and twice the number of "servers" (as
-eahc server has a read and write socket end).
+each server has a read and write socket end).
 I<create> is the time it takes to create a socketpair (which is
 nontrivial) and two watchers: an I/O watcher and a timeout watcher.
 I<request>, the most important value, is the time it takes to handle a
 single "request", that is, reading the token from the pipe and forwarding
-it to another server. This includes deleteing the old timeout and creating
+it to another server. This includes deleting the old timeout and creating
-a new one with a later timeout.
+a new one that moves the timeout into the future.
 =head3 Results
     name sockets create  request
       EV   20000  69.01    11.16
-    Perl   20000  75.28   112.76
+    Perl   20000  73.32    35.87
    Event   20000 212.62   257.32
     Glib   20000 651.16  1896.30
      POE   20000 349.67 12317.24 uses POE::Loop::Event
 =head3 Discussion
 =head3 Summary
 =over 4
-=item * The pure perl implementation performs extremely well, considering
+=item * The pure perl implementation performs extremely well.
-that it uses select.
 =item * Avoid Glib or POE in large projects where performance matters.
 =back
 =head3 Results
     name sockets create request
       EV      16  20.00    6.54
+    Perl      16  25.75   12.62
    Event      16  81.27   35.86
     Glib      16  32.63   15.48
-    Perl      16  24.62  162.37
      POE      16 261.87  276.28 uses POE::Loop::Event
 =head3 Discussion
 The benchmark tries to test the performance of a typical small
 server. While knowing how various event loops perform is interesting, keep
 in mind that their overhead in this case is usually not as important, due
-to the small absolute number of watchers.
+to the small absolute number of watchers (that is, you need efficiency and
+speed most when you have lots of watchers, not when you only have a few of
+them).
 EV is again fastest.
-The C-based event loops Event and Glib come in second this time, as the
+Perl again comes second. It is noticably faster than the C-based event
-overhead of running an iteration is much smaller in C than in Perl (little
+loops Event and Glib, although the difference is too small to really
-code to execute in the inner loop, and perl's function calling overhead is
+matter.
-high, and updating all the data structures is costly).
-The pure perl event loop is much slower, but still competitive.
-POE also performs much better in this case, but is is stillf ar behind the
+POE also performs much better in this case, but is is still far behind the
 others.
 =head3 Summary
 =over 4
 =head1 FORK
 Most event libraries are not fork-safe. The ones who are usually are
-because they are so inefficient. Only L<EV> is fully fork-aware.
+because they rely on inefficient but fork-safe C<select> or C<poll>
+calls. Only L<EV> is fully fork-aware.
 If you have to fork, you must either do so I<before> creating your first
 watcher OR you must not use AnyEvent at all in the child.

Diff Legend

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

Comparing AnyEvent/lib/AnyEvent.pm (file contents): Revision 1.92 by root, Sat Apr 26 04:19:02 2008 UTC vs. Revision 1.104 by root, Wed Apr 30 11:40:22 2008 UTC

Diff Legend

Comparing AnyEvent/lib/AnyEvent.pm (file contents):
Revision 1.92 by root, Sat Apr 26 04:19:02 2008 UTC vs.
Revision 1.104 by root, Wed Apr 30 11:40:22 2008 UTC