--- AnyEvent/lib/AnyEvent.pm 2008/04/26 02:27:30 1.91 +++ AnyEvent/lib/AnyEvent.pm 2008/04/27 03:31:53 1.97 @@ -961,6 +961,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 @@ -1037,7 +1047,7 @@ In this benchmark, we use 10000 socketpairs (20000 sockets), of which 100 (1%) are active. This mirrors the activity of large servers with many -connections, most of which are idle during at any one point in time. +connections, most of which are idle at any one point in time. Source code for this benchmark is found as F in the AnyEvent distribution. @@ -1045,15 +1055,15 @@ =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. I, 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 -a new one with a later timeout. +it to another server. This includes deleting the old timeout and creating +a new one that moves the timeout into the future. =head3 Results @@ -1125,7 +1135,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 +1148,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