Add discussion of impact

pep-0556.rst

@@ -338,6 +338,36 @@ thread requesting an explicit collection.
 In the end, this PEP choses the behaviour that seems simpler to implement
 based on the pseudo-code above.
 
+Impact on memory use
+--------------------
+
+The "threaded" mode incurs a slight delay in implicit collections compared
+to the default "serial" mode.  This obviously may change the memory profile
+of certain applications.  By how much remains to be measured in real-world
+use, but we expect the impact to remain minor and bearable.  First because
+implicit collections are based on a *heuristic* whose effect does not result
+in deterministic visible behaviour anyway.  Second because the GC deals
+with reference cycles while many objects are reclaimed immediately when their
+last visible reference disappears.
+
+Impact on performance
+---------------------
+
+The pseudo-code above adds two lock operations for each implicit collection
+request in "threaded" mode: one in the thread making the request (a
+``release`` call) and one in the GC thread (an ``acquire`` call).
+It also adds two other lock operations, regardless of the current mode,
+around each actual collection.
+
+We expect the cost of those lock operations to be very small, on modern
+systems, compared to the actual cost of crawling through the chains of
+pointers during the collection itself ("pointer chasing" being one of
+the hardest workloads on modern CPUs, as it lends itself poorly to
+speculation and superscalar execution).
+
+Actual measurements on worst-case mini-benchmarks may help provide
+reassuring upper bounds.
+
 
 Open issues
 ===========