]> granicus.if.org Git - python/commitdiff
bpo-24318: Rewrite the README PGO section. (#6863)
authorGregory P. Smith <greg@krypto.org>
Wed, 16 May 2018 15:34:47 +0000 (10:34 -0500)
committerGitHub <noreply@github.com>
Wed, 16 May 2018 15:34:47 +0000 (10:34 -0500)
* bpo-24318: Rewrite the README PGO section.

Merged from a phone on an airplane. :)

README.rst

index 5420558f0dcaadc2cea2f1c98f8d19494012f468..d30b237a01199cfa109527fca80dbafe96a6b0a2 100644 (file)
@@ -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