--- AnyEvent/lib/AnyEvent.pm	2008/04/26 02:27:30	1.91
+++ AnyEvent/lib/AnyEvent.pm	2008/04/26 11:06:45	1.95
@@ -961,6 +961,11 @@
 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.
+
 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
@@ -1037,7 +1042,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<eg/bench2> in the AnyEvent
 distribution.
@@ -1045,15 +1050,15 @@
 =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
-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