--- AnyEvent/lib/AnyEvent.pm	2008/04/25 07:43:25	1.72
+++ AnyEvent/lib/AnyEvent.pm	2008/04/25 07:49:39	1.75
@@ -901,17 +901,17 @@
 
 =head2 Results
 
-          name watcher bytes create invoke destroy comment
-         EV/EV  400000   244   0.56   0.46    0.31 EV native interface
-        EV/Any  100000   610   3.52   0.91    0.75 EV + AnyEvent watchers
-    CoroEV/Any  100000   610   3.49   0.92    0.75 coroutines + Coro::Signal
-      Perl/Any   16000   654   4.64   1.22    0.77 pure perl implementation
-   Event/Event   16000   523  28.05  21.38    0.86 Event native interface
-     Event/Any   16000   943  34.43  20.48    1.39 Event + AnyEvent watchers
-      Glib/Any   16000  1357  96.99  12.55   55.51 quadratic behaviour
-        Tk/Any    2000  1855  27.01  66.61   14.03 SEGV with >> 2000 watchers
-     POE/Event    2000  6644 108.15 768.19   14.33 via POE::Loop::Event
-    POE/Select    2000  6343  94.69 807.65  562.69 via POE::Loop::Select
+          name watchers bytes create invoke destroy comment
+         EV/EV   400000   244   0.56   0.46    0.31 EV native interface
+        EV/Any   100000   610   3.52   0.91    0.75 EV + AnyEvent watchers
+    CoroEV/Any   100000   610   3.49   0.92    0.75 coroutines + Coro::Signal
+      Perl/Any    16000   654   4.64   1.22    0.77 pure perl implementation
+   Event/Event    16000   523  28.05  21.38    0.86 Event native interface
+     Event/Any    16000   943  34.43  20.48    1.39 Event + AnyEvent watchers
+      Glib/Any    16000  1357  96.99  12.55   55.51 quadratic behaviour
+        Tk/Any     2000  1855  27.01  66.61   14.03 SEGV with >> 2000 watchers
+     POE/Event     2000  6644 108.15 768.19   14.33 via POE::Loop::Event
+    POE/Select     2000  6343  94.69 807.65  562.69 via POE::Loop::Select
 
 =head2 Discussion
 
@@ -937,15 +937,21 @@
 The C<Event> module has a relatively high setup and callback invocation cost,
 but overall scores on the third place.
 
-C<Glib>'s memory usage is quite a bit bit higher, features a faster
-callback invocation and overall lands in the same class as C<Event>.
+C<Glib>'s memory usage is quite a bit bit higher, but it features a
+faster callback invocation and overall ends up in the same class as
+C<Event>. However, Glib scales extremely badly, doubling the number of
+watchers increases the processing time by more than a factor of four,
+making it completely unusable when using larger numbers of watchers
+(note that only a single file descriptor was used in the benchmark, so
+inefficiencies of C<poll> do not account for this).
 
-The C<Tk> adaptor works relatively well, the fact that it crashes with
+The C<Tk> adaptor works relatively well. The fact that it crashes with
 more than 2000 watchers is a big setback, however, as correctness takes
 precedence over speed. Nevertheless, its performance is surprising, as the
 file descriptor is dup()ed for each watcher. This shows that the dup()
 employed by some adaptors is not a big performance issue (it does incur a
-hidden memory cost inside the kernel, though).
+hidden memory cost inside the kernel, though, that is not reflected in the
+figures above).
 
 C<POE>, regardless of underlying event loop (wether using its pure perl
 select-based backend or the Event module) shows abysmal performance and
@@ -964,7 +970,7 @@
 
 The overhead AnyEvent adds is usually much smaller than the overhead of
 the actual event loop, only with extremely fast event loops such as the EV
-adds Anyevent significant overhead.
+adds AnyEvent significant overhead.
 
 And you should simply avoid POE like the plague if you want performance or
 reasonable memory usage.