how do optimization your code

8/12/2019 How Do Optimization Your Code

1/9

How to optimize your code

February 6th, 2011

Disclaimer 1: This post was influenced heavily by my good friend, co-worker, and Haskell hackerEvan.

Disclaimer 2: Unless otherwise noted, I am completely making up terms in this article. I pulled themright out of the ether. Dont expect to find industry conventions that agree with me.

Bob is a fictitious developer on my software team, who suggested that we could speed up some of our

Qt/C++ code. The code under scrutiny is this:

for(int i=0; i


2/9

power of your human brain, which in its own right is a pretty advanced computer, you are wrong. You

just are. Even if you arent wrong (hint: you are wrong), and the only tool you use for optimizing your

code is IBO, then you dont have a way to measure the effect of your code changes on your programs

actual speed.

All but the most obvious performance problems require tools to measure the effect of your code

changes, and the most heinous problems require tools to identify where the bottle-necks are evenhappening.

Ive lost track of the number of times Ive used IBO to try to speed up some code, and failed. For

example, it shouldbe faster to use a hash-based lookup, like QHash, instead of a BST-based lookup,

like QMap, in theory. In practice, though, there are other considerations. How many elements are in

your data structure? How fast are the elements hash-code functions vs. their comparison operators?

Just because an algorithm is O(1) doesnt mean its faster than an O(n) algorithm. There are just too

many other variables besides order of complexity (not to mention, big O notation really only applies

to theoretically very large datasets anyway).

So, if Intuition-based Optimization is so crappy at actually making code faster, then what is the rightway?

Evidence-based Optimization

Or EBO, for short. This is where you use actual evidence to diagnose performance problems and

measure the speed impact of your code changes. There are several techniques for doing this. Lets look

at a few.

Technique 1: The time command

In the simplest of situations, all you want to know is how long it takes your (command line) program to

run. If youre using a Unix-ish operating system like Linux or Mac OS X, you can use the time

command to do this. Heres an example:

$ time some-program

real 0m2.235s

user 0m0.155s

sys 0m0.075s

In a nutshell, the time command will tell you how long your program took to run. Look at the real

time to get this info. The other two times listed tell you a little about whereyour program spent its time,

and you can read a lot of cryptic details about these numbers fromthe time man page.For most simple

applications, the real time is adequate.
http://unixhelp.ed.ac.uk/CGI/man-cgi?timehttp://unixhelp.ed.ac.uk/CGI/man-cgi?timehttp://unixhelp.ed.ac.uk/CGI/man-cgi?timehttp://unixhelp.ed.ac.uk/CGI/man-cgi?time


3/9

Technique 2: Measuring time in your program

A more common case is that a subset of your application is running slowly, but you dont know

exactly where. Maybe you have an educated guess where the code is getting bogged down, but you

want to use actual evidence to identify the code that is causing the problem (congratulations on wanting

to use evidence instead of intuition by the way).

If youre using Qt and C++ (which by the way is the only non-insane way to write C++ code), you can

use theQTimeclass to do this. If you are using version 4.7 or newer, you can use theQElapsedTimer

class for a little bit more precision, but I have not needed that much more precision.

Heres how you use QTime:

QTime time;

time.start()

// Code to measure goes here

qDebug()


4/9

result of a user action, like a button click). This can be handy when there are multiple threads involved

to measure the sum total execution time.

Lets use this technique to measure Fictitious Bobs opening example from above.

Which of these two approaches is faster?

Exhibit A:

for(int i=0; i


5/9

time.start();

SomeClass *ptr;

for(int i=0; i


6/9

In this case, YSlow will tell you which parts of your web display are taking the longest to appear on the

users web browser, which sometimes can tell you a great deal about where your code needs to be

optimized.

Technique 5: Profilers

Profilers are a special animal and require careful usage to produce useful results. Almost all of myprofiler experience comes from Valgrind on Linux. Running your application under Valgrind produces

a log file that lists every function call and how long was spent in each. This can be both useful and

overwhelming in sheer quantity of information.

Of course, Valgrind is a very complicated tool, but here are some simple usage examples to get you

started.

To profile your application fully, use the callgrindtool like so:

valgrind --tool=callgrind /path/to/your/application

That produces a file (sometimes multiple files) called something like callgrind.out. Dont try to readthat file with an editor. Instead, use an application called KCacheGrind, like so:

kcachegrind callgrind.out

Youll see something like this:

Theres no easy path at this point. Youll have to look at the flood of results and carefully try to learn

where your application is spending its time. Notice that KCacheGrind will show you how much time is


7/9

spent in each function and how much time is spent in callee functions, which lets you determine

where the heavy lifting is actually happening.

I often like to use the callee graph on the right-hand side to see, by geometry, which functions are the

most used. This often tells you which standard library or Qt core classes are being used the most, which

can provide a hint as to which of your own code is the culprit

Technique 6: Stochastic Profiling

Disclaimer: I did not invent this term. I heard it first from my brilliant co-worker, Shane, who I believe

borrowed it from another discipline.

Sometimes an application will go into a CPU hogging run-away state and its impossible to tell where

in the code this is happening. If it lasts for more than a moment, you can use a technique called

stochastic profilingto sample the programs state to get a snapshot of the current function call tree.

There are several techniques for doing this.

On Mac OS X, you can use the Activity Monitors Sample Process button, and see a nice call graph,

shown below for the Mail application:


8/9

On Linux, you can achieve the same thing using gdbto attach to a process by pid (make sure you have

the right permissions), and run the btcommand to see where its currently executing.

If you do this a few times, you can start to get a feel for where the program is spending its time.

Conclusion

There you have it. Remember that when it comes to optimizing your code for speed, dont believe your

intuition, and learn to use tools to measure your code. Remember to measure, modify, and re-measure.

Happy optimizing!


9/9

how do optimization your code

Documents