--- AnyEvent/lib/AnyEvent.pm 2008/04/27 16:31:48 1.98 +++ AnyEvent/lib/AnyEvent.pm 2008/04/29 07:15:49 1.103 @@ -68,26 +68,6 @@ useful) and you want to force your users to use the one and only event model, you should I use this module. -#TODO# - -Net::IRC3 -AnyEvent::HTTPD -AnyEvent::DNS -IO::AnyEvent -Net::FPing -Net::XMPP2 -Coro - -AnyEvent::IRC -AnyEvent::HTTPD -AnyEvent::DNS -AnyEvent::Handle -AnyEvent::Socket -AnyEvent::FPing -AnyEvent::XMPP -AnyEvent::SNMP -Coro - =head1 DESCRIPTION L provides an identical interface to multiple event loops. This @@ -479,6 +459,78 @@ loading the C 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 + +Contains various utility functions that replace often-used but blocking +functions such as C by event-/callback-based versions. + +=item L + +Provide read and write buffers and manages watchers for reads and writes. + +=item L + +Provides a means to do non-blocking connects, accepts etc. + +=item L + +Provides a simple web application server framework. + +=item L + +Provides asynchronous DNS resolver capabilities, beyond what +L offers. + +=item L + +The fastest ping in the west. + +=item L + +AnyEvent based IRC client module family. + +=item L + +AnyEvent based XMPP (Jabber protocol) module family. + +=item L + +AnyEvent-based implementation of the Freenet Client Protocol, birthplace +of AnyEvent. + +=item L + +High level API for event-based execution flow control. + +=item L + +Has special support for AnyEvent. + +=item L + +The lambda approach to I/O - don't ask, look there. Can use AnyEvent. + +=item L + +Truly asynchronous I/O, should be in the toolbox of every event +programmer. Can be trivially made to use AnyEvent. + +=item L + +Truly asynchronous Berkeley DB access. Can be trivially made to use +AnyEvent. + +=back + =cut package AnyEvent; @@ -1021,17 +1073,22 @@ hidden memory cost inside the kernel which is not reflected in the figures above). -C, regardless of underlying event loop (whether using its pure -perl select-based backend or the Event module, the POE-EV backend -couldn't be tested because it wasn't working) shows abysmal performance -and memory usage: Watchers use almost 30 times as much memory as -EV watchers, and 10 times as much memory as Event (the high memory +C, regardless of underlying event loop (whether using its pure perl +select-based backend or the Event module, the POE-EV backend couldn't +be tested because it wasn't working) shows abysmal performance and +memory usage with AnyEvent: Watchers use almost 30 times as much 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. The design of the POE adaptor class in AnyEvent can not -really account for this, as session creation overhead is small compared -to execution of the state machine, which is coded pretty optimally within -L. POE simply seems to be abysmally slow. +implementation. + +The design of the POE adaptor class in AnyEvent can not really account +for the performance issues, though, as session creation overhead is +small compared to execution of the state machine, which is coded pretty +optimally within L (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 @@ -1088,7 +1145,7 @@ 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 @@ -1120,8 +1177,7 @@ =over 4 -=item * The pure perl implementation performs extremely well, considering -that it uses select. +=item * The pure perl implementation performs extremely well. =item * Avoid Glib or POE in large projects where performance matters. @@ -1144,9 +1200,9 @@ 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 @@ -1160,12 +1216,9 @@ EV is again fastest. -The C-based event loops Event and Glib come in second this time, as the -overhead of running an iteration is much smaller in C than in Perl (little -code to execute in the inner loop, and perl's function calling overhead is -high, and updating all the data structures is costly). - -The pure perl event loop is much slower, but still competitive. +Perl again comes second. It is noticably faster than the C-based event +loops Event and Glib, although the difference is too small to really +matter. POE also performs much better in this case, but is is still far behind the others.