--- AnyEvent/lib/AnyEvent.pm 2008/04/26 04:19:52 1.93 +++ AnyEvent/lib/AnyEvent.pm 2008/04/27 19:36:55 1.101 @@ -68,7 +68,6 @@ useful) and you want to force your users to use the one and only event model, you should I use this module. - =head1 DESCRIPTION L provides an identical interface to multiple event loops. This @@ -460,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; @@ -946,7 +1017,7 @@ 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 @@ -961,6 +1032,16 @@ 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 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 @@ -1045,7 +1126,7 @@ =head3 Explanation of the columns I 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 is the time it takes to create a socketpair (which is nontrivial) and two watchers: an I/O watcher and a timeout watcher. @@ -1059,7 +1140,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 @@ -1115,9 +1196,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 @@ -1125,7 +1206,9 @@ 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. @@ -1136,7 +1219,7 @@ 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