A guide to analyzing Python performance - Python Performance, 6 of n

A guide to analyzing Pythonperformance

While it’s not alwaysthe case that every Python program you write will require a rigorousperformance analysis, it is reassuring to know that there are a wide variety oftools in Python’s ecosystem that one can turn to when the time arises.

Analyzing a program’sperformance boils down to answering 4 basic questions:

1.       How fast is it running?

2.       Where are the speed bottlenecks?

3.       How much memory is it using?

4.       Where is memory leaking?

Below, we’ll dive intothe details of answering these questions using some awesome tools.

Let’s begin by using aquick and dirty method of timing our code: the good old unix utilitytime.

The meaning betweenthe three output measurements are detailed in this stackoverflow article,but in short

·        real - refers to theactual elasped time

·        user - refers to theamount of cpu time spent outside of kernel

·        sys - refers to theamount of cpu time spent inside kernel specific functions

You can get a sense ofhow many cpu cycles your program used up regardless of other programs runningon the system by adding together the sys and user times.

If the sum of sys and user times is much less than real time, then you can guess that most yourprogram’s performance issues are most likely related to IO waits.

Our next techniqueinvolves direct instrumentation of the code to get access to finer grain timinginformation. Here’s a small snippet I’ve found invaluable for making ad-hoctiming measurements:

timer.py

In order to use it,wrap blocks of code that you want to time with Python’s with keyword and this Timer context manager. It will take care of startingthe timer when your code block begins execution and stopping the timer whenyour code block ends.

Here’s an example useof the snippet:

I’ll often log theoutputs of these timers to a file in order to see how my program’s performanceevolves over time.

Robert Kern has a niceproject called line_profiler which I often use to see how fast and howoften each line of code is running in my scripts.

To use it, you’ll needto install the python package via pip:

Once installed you’llhave access to a new module called “line_profiler” as well as an executablescript “kernprof.py”.

To use this tool,first modify your source code by decorating the function you want to measurewith the @profile decorator. Don’tworry, you don’t have to import anyting in order to use this decorator. The kernprof.py script automatically injects it into yourscript’s runtime during execution.

primes.py

Once you’ve gottenyour code setup with the @profile decorator, use kernprof.py to run your script.

The -l option tells kernprof to inject the @profile decorator into your script’s builtins, and -v tells kernprof to display timing informationonce you’re script finishes. Here’s one the output should look like for theabove script:

Look for lines with ahigh amount of hits or a high time interval. These are the areas whereoptimizations can yield the greatest improvements.

Now that we have agood grasp on timing our code, let’s move on to figuring out how much memoryour programs are using. Fortunately for us, Fabian Pedregosa has implemented anicememory profiler modeled after Robert Kern’s line_profiler.

First install it viapip:

(Installing the psutil package here is recommended because it greatlyimproves the performance of the memory_profiler).

Like line_profiler,memory_profiler requires that you decorate your function of interest with an@profile decorator like so:

To see how much memoryyour function uses run the following:

You should see outputthat looks like this once your program exits:

A little known featureof line_profiler and memory_profiler is that both programs have shortcut commandsaccessible from within IPython. All you have to do is type the following withinan IPython session:

Upon doing so you’llhave access to the magic commands %lprun and %mprun which behave similarlyto their command-line counterparts. The major difference here is that you won’tneed to decorate your to-be-profiled functions with the @profile decorator. Just go ahead and run the profilingdirectly within your IPython session like so:

This can save you alot of time and effort since none of your source code needs to be modified inorder to use these profiling commands.

The cPythoninterpreter uses reference counting as it’s main method of keeping track ofmemory. This means that every object contains a counter, which is incrementedwhen a reference to the object is stored somewhere, and decremented when areference to it is deleted. When the counter reaches zero, the cPythoninterpreter knows that the object is no longer in use so it deletes the objectand deallocates the occupied memory.

A memory leak canoften occur in your program if references to objects are held even though theobject is no longer in use.

The quickest way tofind these “memory leaks” is to use an awesome tool called objgraphwritten byMarius Gedminas. This tool allows you to see the number of objects in memoryand also locate all the different places in your code that hold references tothese objects.

To get started, firstinstall objgraph:

Once you have thistool installed, insert into your code a statement to invoke the debugger:

Which objects are the most common?

At run time, you caninspect the top 20 most prevalent objects in your program by running:

Which objects have been added or deleted?

We can also see whichobjects have been added or deleted between two points in time:

What is referencing this leaky object?

Continuing down thisroute, we can also see where references to any given object is being held.Let’s take as an example the simple program below:

To see what is holdinga reference to the variable x, run the objgraph.show_backref()function:

The output of thatcommand should be a PNG image stored at /tmp/backrefs.png and it should look something like this:

The box at the bottomwith red lettering is our object of interest. We can see that it’s referencedby the symbol x once and by the list y three times. If x is the object causing a memory leak, we canuse this method to see why it’s not automatically being deallocated by trackingdown all of its references.

So to review, objgraph allows us to:

·        show the top N objectsoccupying our python program’s memory

·        show what objects havebeen deleted or added over a period of time

·        show all references toa given object in our script

In this post, I’veshown you how to use several tools to analyze a python program’s performance.Armed with these tools and techniques you should have all the informationrequired to track down most memory leaks as well as identify speed bottlenecksin a Python program.

As with many othertopics, running a performance analysis means balancing the tradeoffs betweeneffort and precision. When in doubt, implement the simplest solution that willsuit your current needs.

Refrences

·        stack overflow - time explained

·        line_profiler

·        memory_profiler

·        objgraph