--- AnyEvent/lib/AnyEvent.pm	2008/04/25 08:41:38	1.76
+++ AnyEvent/lib/AnyEvent.pm	2008/04/25 09:06:27	1.78
@@ -138,7 +138,7 @@
 my variables are only visible after the statement in which they are
 declared.
 
-=head2 IO WATCHERS
+=head2 I/O WATCHERS
 
 You can create an I/O watcher by calling the C<< AnyEvent->io >> method
 with the following mandatory key-value pairs as arguments:
@@ -708,7 +708,7 @@
 
 =head1 EXAMPLE PROGRAM
 
-The following program uses an IO watcher to read data from STDIN, a timer
+The following program uses an I/O watcher to read data from STDIN, a timer
 to display a message once per second, and a condition variable to quit the
 program when the user enters quit:
 
@@ -869,10 +869,15 @@
 over the event loops themselves (and to give you an impression of the
 speed of various event loops), here is a benchmark of various supported
 event models natively and with anyevent. The benchmark creates a lot of
-timers (with a zero timeout) and io watchers (watching STDOUT, a pty, to
+timers (with a zero timeout) and I/O watchers (watching STDOUT, a pty, to
 become writable, which it is), lets them fire exactly once and destroys
 them again.
 
+Rewriting the benchmark to use many different sockets instead of using
+the same filehandle for all I/O watchers results in a much longer runtime
+(socket creation is expensive), but qualitatively the same figures, so it
+was not used.
+
 =head2 Explanation of the columns
 
 I<watcher> is the number of event watchers created/destroyed. Since
@@ -930,10 +935,11 @@
 
 The pure perl implementation is hit in a few sweet spots (both the
 zero timeout and the use of a single fd hit optimisations in the perl
-interpreter and the backend itself). Nevertheless tis shows that it
-adds very little overhead in itself. Like any select-based backend its
-performance becomes really bad with lots of file descriptors, of course,
-but this was not subject of this benchmark.
+interpreter and the backend itself, and all watchers become ready at the
+same time). Nevertheless this shows that it adds very little overhead in
+itself. Like any select-based backend its performance becomes really bad
+with lots of file descriptors (and few of them active), of course, but
+this was not subject of this benchmark.
 
 The C<Event> module has a relatively high setup and callback invocation cost,
 but overall scores on the third place.