diff --git a/pep-0649.rst b/pep-0649.rst
index c0189a838..c85484f15 100644
--- a/pep-0649.rst
+++ b/pep-0649.rst
@@ -1080,12 +1080,13 @@ shortly.
 Performance Comparison
 ======================
 
-Performance with this PEP is generally favorable.  There are three
+Performance with this PEP is generally favorable.  There are four
 scenarios to consider:
 
 * the runtime cost when annotations aren't defined,
 * the runtime cost when annotations are defined but *not* referenced, and
-* the runtime cost when annotations are defined *and* referenced.
+* the runtime cost when annotations are defined and referenced as objects.
+* the runtime cost when annotations are defined and referenced as strings.
 
 We'll examine each of these scenarios in the context of all three
 semantics for annotations: stock, :pep:`563`, and this PEP.
@@ -1112,7 +1113,7 @@ being annotated:
   class namespace or closure, this object will be a tuple constructed
   at binding time.
 
-When annotations are both defined and referenced, code using
+When annotations are both defined and referenced as objects, code using
 this PEP should be much faster than :pep:`563`, and be as fast
 or faster than stock.  :pep:`563` semantics requires invoking
 ``eval()`` for every value inside an annotations dict which is
@@ -1121,6 +1122,11 @@ more efficient bytecode for class and module annotations than stock
 semantics; for function annotations, this PEP and stock semantics
 should be about the same speed.
 
+The one case where this PEP will be noticeably slower than :pep:`563` is when
+annotations are requested as strings; it's hard to beat "they are already
+strings." But stringified annotations are intended for online documentation use
+cases, where performance is less likely to be a key factor.
+
 Memory use should also be comparable in all three scenarios across
 all three semantic contexts.  In the first and third scenarios,
 memory usage should be roughly equivalent in all cases.