diff --git a/doc/ref/vm.texi b/doc/ref/vm.texi
index 6616af446..ba31d7ccb 100644
--- a/doc/ref/vm.texi
+++ b/doc/ref/vm.texi
@@ -80,11 +80,12 @@ but it is not normally used at runtime.)
 
 The upside of implementing the interpreter in Scheme is that we preserve
 tail calls and multiple-value handling between interpreted and compiled
-code. The downside is that the interpreter in Guile 2.2 is still slower
-than the interpreter in 1.8. We hope the that the compiler's speed makes
-up for the loss.  In any case, once we have native compilation for
-Scheme code, we expect the new self-hosted interpreter to beat the old
-hand-tuned C implementation.
+code. The downside is that the interpreter in Guile 2.2 is still about
+twice as slow as the interpreter in 1.8.  Since Scheme users are mostly
+running compiled code, the compiler's speed more than makes up for the
+loss.  In any case, once we have native compilation for Scheme code, we
+expect the self-hosted interpreter to handily beat the old hand-tuned C
+implementation.
 
 Also note that this decision to implement a bytecode compiler does not
 preclude native compilation. We can compile from bytecode to native
@@ -213,8 +214,9 @@ variables are allocated in ``boxes''---actually, in variable cells.
 variables are indirected through the boxes.
 
 Thus perhaps counterintuitively, what would seem ``closer to the
-metal'', viz @code{set!}, actually forces an extra memory allocation
-and indirection.
+metal'', viz @code{set!}, actually forces an extra memory allocation and
+indirection.  Sometimes Guile's optimizer can remove this allocation,
+but not always.
 
 Going back to our example, @code{b} may be allocated on the stack, as
 it is never mutated.