bpo-24318: Rewrite the README PGO section. (GH-6863)

* bpo-24318: Rewrite the README PGO section.

Merged from a phone on an airplane. :)
(cherry picked from commit 93f9a8a5afb58b1d2e4f27bb46d3d4e0fa8c08f0)

Co-authored-by: Gregory P. Smith <greg@krypto.org>

diff --git a/README.rst b/README.rst
index ffa9631b028765debc2a6e2d4040e36674fdad9f..2341b53c710224ddf385c249b5895718e821119a 100644 (file)
--- a/README.rst
+++ b/README.rst
@@ -93,25 +93,26 @@ Profile Guided Optimization
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 PGO takes advantage of recent versions of the GCC or Clang compilers.  If used,
-either via ``configure --enable-optimizations`` above or by manually running
-``make profile-opt`` regardless of configure flags it will do several steps.
-
-First, the entire Python directory is cleaned of temporary files that may have
-resulted in a previous compilation.
-
-Then, an instrumented version of the interpreter is built, using suitable
-compiler flags for each flavour. Note that this is just an intermediary step.
-The binary resulting from this step is not good for real life workloads as
-it has profiling instructions embedded inside.
-
-After this instrumented version of the interpreter is built, the Makefile will
-automatically run a training workload. This is necessary in order to profile
-the interpreter execution. Note also that any output, both stdout and stderr,
-that may appear at this step is suppressed.
-
-Finally, the last step is to rebuild the interpreter, using the information
-collected in the previous one. The end result will be a Python binary that is
-optimized and suitable for distribution or production installation.
+either via ``configure --enable-optimizations`` or by manually running
+``make profile-opt`` regardless of configure flags, the optimized build
+process will perform the following steps:
+
+The entire Python directory is cleaned of temporary files that may have
+resulted from a previous compilation.
+
+An instrumented version of the interpreter is built, using suitable compiler
+flags for each flavour. Note that this is just an intermediary step.  The
+binary resulting from this step is not good for real life workloads as it has
+profiling instructions embedded inside.
+
+After the instrumented interpreter is built, the Makefile will run a training
+workload.  This is necessary in order to profile the interpreter execution.
+Note also that any output, both stdout and stderr, that may appear at this step
+is suppressed.
+
+The final step is to build the actual interpreter, using the information
+collected from the instrumented one.  The end result will be a Python binary
+that is optimized; suitable for distribution or production installation.
 
 
 Link Time Optimization