Update running.rst

Author: rocky

docs/commands/running.rst

@@ -3,14 +3,14 @@ Running
 
 Running, restarting, or stopping the program.
 
-When a program is stopped there are several possibilities for further
+When a program is stopped, there are several possibilities for further
 program execution. You can:
 
 * terminate the program inside the debugger
 * restart the program
 * continue its execution until it would normally terminate or until a
   breakpoint is hit
-* step execution which is runs for a limited amount of code before stopping
+* step execution, which runs for a limited amount of code before stopping
 
 About Debugging Overhead
 ------------------------
@@ -19,23 +19,22 @@ Explanation of Problem
 ~~~~~~~~~~~~~~~~~~~~~~
 
 When you enable the debugger, there are callbacks made in the running
-of the program when certain events happen. Events are things occur in
+of the program when certain events happen. Events are things that occur in
 running the program, like when the code reaches a new line in the
-program, when a call or return occur, or when an exception is raised.
+program, when a call or return occurs, or when an exception is raised.
 
 The overhead in running these callbacks slows down your
 program. Currently, the overhead can be greater than the overhead in
 ``pdb``. This is because the debugger tries to be more precise and
-careful it tracing, and the features it provides are more powerful. In
-most cases, we can do this without a significatn slow down in the
+careful in its tracing, and the features it provides are more powerful. In
+most cases, we can do this without a significant slowdown in the
 debugged program.
 
 But in certain situations, the overhead in running debugged code can
 be large. This happens when we want to "step over" a function that is
-large and complex like an ``import`` of a large module.
+large and complex, like an ``import`` of a large module.
 
-For example, if you turn on the debugger and run the ``import pandas``
-instruction, it can increase your CPU for a while.  ::
+For example, if you turn on the debugger and run the ``import pandas`` instruction, it can increase your CPU usage for a while.  ::
 
    $ cat slow.py
    #!/usr/bin/env python3
@@ -55,7 +54,7 @@ The debugger overhead only concerns the instructions of the program to
 be debugged, the instructions of the trepan3k interpreter are not
 analyzed.
 
-Given this, here is how to speed up the above  ::
+Given this, here is how to speed up the above ::
 
    $ trepan3k slow.py
    (/tmp/slow.py:1): <module>
@@ -67,7 +66,7 @@ Given this, here is how to speed up the above  ::
    (/tmp/slow.py:2 @10): <module>
    -- 2 print(pd)
 
-Alternatively, modifying the program with a call to ``debug`` will also run fast ::
+Alternatively, modifying the program with a call to ``debug`` will also run fast::
 
    $ cat fast.py
    #!/usr/bin/env python3
@@ -92,10 +91,9 @@ Techniques to Reduce Debugger Overhead
 
 #. Remove keep breakpoints when you no longer need them
 
-When there are *any* breakpoints in the program, the debugger has to
-check every event to see if the event is the target of a breakpoint.
+When there are *any* breakpoints in the program, the debugger has to check every event to see if the event is the target of a breakpoint.
 
-In particular the ``continue``, ``finish``, and ``next`` (step over) commands are much slower.
+In particular, the ``continue``, ``finish``, and ``next`` (step over) commands are much slower.
 
 Therefore, remove *all* breakpoints when they are no longer
 needed. Consider using temporary or one-time breakpoints when you need to stop only once.
@@ -105,20 +103,18 @@ needed. Consider using temporary or one-time breakpoints when you need to stop o
 
 ``continue`` when there are no breakpoints pending probably gives the
 fastest execution. ``info break`` will show you if there are any
-breakpoints. Recall that one-time breakopints are removed after they
+breakpoints. Recall that one-time breakpoints are removed after they
 are encountered.
 
-When there are no breakpoints using the ``continue`` command will cause
-the debugger will remove its trace hook, and execution should continue at normal speed.
+When no breakpoints are used, the ``continue`` command will cause the debugger to remove its trace hook, and execution should continue at normal speed.
 
 The ``step`` is usually fast, because there is generally very little
 debugger overhead between stopping points.
 
-The ``next`` (step over) debugger command is faster without breakpoint
-than when there are breakpoint because without breakpoints there is
+The ``next`` (step over) debugger command is faster without a breakpoint than when there are breakpoint because without breakpoints, there is
 less debugger overhead in checking for the stopping condition.
 
-The ``finish`` command when there are no breakpoint is faster than when there are breakpoints.
+The ``finish`` command when there are no breakpoints is faster than when there are breakpoints.
 Without breakpoints debugger will remove tracing calls.
 
 When there must breakpoint in use, setting a breakpoint and running