Index: doc/papers/concurrency/response2
===================================================================
--- doc/papers/concurrency/response2	(revision 393d59a90f59576e7d77b5d3c2e7b153655897dd)
+++ doc/papers/concurrency/response2	(revision b54118ad23651a1d9e49d473d666db9fc0d8cd48)
@@ -692,10 +692,16 @@
 choosing between a generator or coroutine; either form can receive (input) or
 return (output) millions of values. As well, simple versus complex computations
-is also not a criterion for selection as both forms can be very
-sophisticated. As stated in the paper, a coroutine brings generality to the
-implementation because of the addition stack, whereas generators have
-restrictions on standard software-engining practices: variable placement, no
-helper functions without creating an explicit generator stack, and no symmetric
-control-flow.
+is also not an absolute criterion for selection as both forms can be simple or
+complex.
+
+As stated in the paper, a coroutine brings generality to the implementation
+because of the addition stack, whereas generators have restrictions on standard
+software-engineering practices: variable placement, no helper functions without
+creating an explicit generator stack, and no symmetric control-flow.  It is
+true that simple generators probably suffer less from restrictions. Also,
+simplicity means the amount of work done is small so the cost of the
+suspend/resume becomes a factor, where experiments show suspend/resume for a
+generator is 10 times faster than for a coroutines.
+
 
     * prefer threads for cases where parallel execution is desired or needed.