Profiling
26-Jul-16
Optimization


Optimization is the process of making a program as fast (or as
small) as possible
Here’s what the experts say about optimization:





Sir Tony Hoare: “Premature optimization is the root of all evil.”
Donald Knuth: “We should forget about small efficiencies, say about
97% of the time: premature optimization is the root of all evil.”
W. A. Wulf: “More computing sins are committed in the name of
efficiency (without necessarily achieving it) than for any other single
reason - including blind stupidity.”
Michael A. Jackson:
“The First and Second Rules of Program Optimization:
1. Don’t do it.
2. (For experts only!) Don’t do it yet.”
Richard Carlson: “Don’t sweat the small stuff.”
When should you optimize?

Optimize when (and only when):




One of the major principles of the XP (Extreme Programming)
approach is: “Do the simplest thing that could possibly work.”



A program you have written is taking too long to run
A method you have written will be called millions or billions of times in a
highly graphics-intensive application
Your code is going into the kernel of an operating system
In other words, don’t use a faster method in preference to a simpler one
If it turns out to be too slow, you can fix it later
However: If efficiency is completely ignored in a large project, it
may be very difficult to fix it later

Individual methods can be improved, but if the overall design of the
project is inefficient, redesign can be prohibitively expensive
What should you optimize?


From Wikipedia: In engineering, bottleneck is a phenomenon
where the performance or capacity of an entire system is limited
by a single component
The 90/10 rule is: 90% of the runtime is taken up by 10% of the
code



How do you find the bottleneck?



That 10% is the bottleneck
This is where significant improvements can be made
Intuition is surprisingly inaccurate
A profiler is a program that measures which parts of your program are
taking the most time (or using the most memory)
Use a profiler before you waste your time optimizing the wrong
part of the program!
What shouldn’t you optimize?



Don’t sweat the small stuff
Virtually any modern compiler is better at optimization than you
are
Consider:
for (int i = 0; i < array.length; i++) {
int limit = 100;
if (array[i] > limit) array[i] = limit;
}
Would this be faster if you took the assignment to limit out of the
loop?


No! The compiler will do that anyway
In fact, there is a fair chance that doing so would slow your program
down!
How should you optimize?

The best way to speed up a bottleneck is to avoid doing
it altogether!

Example: In one case study I read about, one program added
debugging information to a dataset; the dataset was sent to a
second program, which stripped off the debugging
information before using the dataset


The second best way is to find a faster algorithm


Eliminating the debugging information doubled the speed of the
program
This what a course in “Analysis of Algorithms” is all about
Always remember, though, that in “real life” you
should use a profiler to find out what to optimize

The fastest sorting algorithm in the world won’t help you
very much if you’re sorting a 10-element array
Aside: Timing without a profiler


Here’s an easy way to time a section of code:
long t = System.currentTimeMillis();
// code to be timed goes here
t = System.currentTimeMillis() - t;
System.out.println(t + " milliseconds");
Basic use of the NetBeans Profiler

First, make sure the
project you want to
profile is NetBean’s
“Main Project”
Adding the profiler to the project


Next, choose Profile > Profile Main Project...
You will get the following message; just click OK
Profile execution speeds

1
Next, click CPU, then Part of application, then edit...
2
3
Select root methods

Select the
methods you
want to
profile, then
click OK
Run the program

Click the Run button
Look at the results


I’ve left out a couple of obvious steps
This is just a very basic introduction--you should
explore some of the options yourself
Problems with profiling

Profiling is not as useful for distributed code


For example, an application that runs on a server, accesses a database,
makes remote calls, does input/output, etc., is too distributed for profiling
to be much help
Environment “noise” can be a problem

Profiling is more meaningful in the absence of “alien” code, network
access, input/output, etc.


Try to isolate the code to be profiled from these factors
Many Java compilers interpret the code the first time through,
rather than compile it


Run the code being tested multiple times, rather than just once
Longer runs are better; ideally, your profiling run should take tens of
seconds, or a few minutes
The End