Performance

1. Performance • Code Complete 2 – Chapters 25/26 and Chapter 7 of K&P • Compare today to 44 years ago • The Burroughs B1700 – circa 1974 • Why do we care about performance today? • First principle of optimization: • DON’T • Second principle of optimization: • DON’T • Third principle of optimization • DON’T

2. Optimization • Easiest technique is to turn on the compiler’s optimizer • In VS.NET do a release build vs. debug build • Makes debugging harder • Hopefully doesn’t introduce new bugs • But could if there are non-deterministic parts of the program already • Also, debug mode is known to initialize locations for easy debugging but your code may count on that initialization

3. Optimization - 2 • Measurement is the critical component before deciding that you should worry about performance improvement • Make sure that you have good regression tests • Eliminates issue of optimizing something so it is so fast that you forgot to preserve the semantics and it doesn’t work any more  • Often algorithm analysis is the most fruitful place to start • How much faster is binary search than linear search on a one million element array? • See you in CS 4150!

4. Targets of Improvement • Program design: how a program is divided into classes may make it hard or easy to improve performance • Class & method design: choice of data types, algorithms • Operating system interactions • Code compilation: the right compiler may be all you need • Hardware: why not a hardware upgrade? • Code tuning: small scale changes to correct code with hopes of running faster (or smaller)

5. Timing • Easiest is to use time mechanism provided by system • 5 faith> time clean.csh • 0.0u 2.0s 0:08 24% 0+0k 0+0io 0pf+0w • 6 faith> • How about on Windows? • C:\Documents and Settings\kessler>time • The current time is: 10:06:08.06 • Enter the new time: • C:\Documents and Settings\kessler> • So, what should you do on systems like Windows to get a coarse view of time? • #include <time.h> • double begin = clock(); • … • double result = clock() – begin; // time in ms

6. The Pareto Principle (20% of Italians have 80% of the wealth) You can get 80% of the result with 20% of the effort. • 20% of a program consumes 80% of its execution time (Boehm) • Less than 4% of a program accounts for more than 50% of the run time (Knuth) • Measure your code for hot spots, and then put resources into optimizing the small portion(s) of the program used most

7. Profiling • What is a profile? • A measure of where a program spends its time • Provides more detailed timing information about a program • Number of times a function is called • Percentage of execution time spent in a function • Some provide the information in a line by line fashion • Profiling is effective for finding hot spots in a program • How does a profiler work?

8. Misconceptions • Reducing the lines of code in a high-level language improves the speed or size of the resulting machine code • Certain operations are probably faster or smaller than others • You should optimize as you go • A fast program is as important as a correct one • A fast program is as important as a readable one

9. Strategies • After deciding that you HAVE to optimize: • Measure • Track down slow parts • Remember important principle – if you improve one part so it takes no time, your program will only get x% faster if the part you are optimizing is taking x% of the time • Use a better algorithm or data structure • Try to determine complexity • Enable compiler optimizations • Measure before and after to make sure it is worth it • Tune the code • Adjust the loops and expressions to be faster • Don’t optimize what doesn’t matter • Rule of thumb – your time vs. how much time you’ll save over the lifetime of the program

10. Tuning The Code • Collect common subexpressions • Is probably not worth it these days • Reduction in strength of operations • Again is probably not worth it these days • Unroll or eliminate loops • Short loop vs. 3 lines • Again – many good compilers will do this already • Cache frequently used values • Again – compilers are pretty good at this • Rewrite in a lower-level language • Costs programmer time • Good, modern compilers • Already do much of this • Are often better at it than you are • Are faster • Better at optimizing straightforward code than tricky code • Can often improve your code by 40% or more!!

11. Quote from McConnell – About Code-Tuning Optimizations “Computers are dramatically faster and memory is more plentiful. In the first edition [written 10 years ago], I ran most of the tests in this chapter [26] 10,000 to 50,000 times to get meaningful, measurable results. For this edition I had to run most tests 1 million to 100 million times. When you have to run a test 100 million times to get measurable results, you have to ask whether anyone will ever notice the impact in a real program. Computers have become so powerful that for many common kinds of programs, the level of performance optimization discussed in this chapter has become irrelevant. … People writing desktop applications may not need this information, but people writing software for embedded systems, real-time systems, and other systems with strict speed or space restrictions can still benefit from it.” – pg 643-644, Chapter 26.7, Code Complete 2.

12. Space Efficiency • Time is not the only measure of a program’s performance • Which is more important space or time? • First principle of space optimization? • Don’t do it • What is paging? Caching? Why do we care? • Use the smallest possible data type • int vs. short • Don’t store what you can easily recompute • What tradeoff is going on here? • Image compression description is a good one to consider

13. Summary • The best is the enemy of the good • Don’t do space or time optimization • Unless you have to • Unless you have measured it • Unless you know where the hot spots are • Unless you decide what real improvements are possible • Check algorithms and data structures • Can have the single most benefit • “Don’t put lipstick on a pig!!! ” • Turn on compiler optimization • Be careful of hardware differences • A PC with a big cache vs. no cache • Resort to detailed tuning only as last resort or if your environment demands it

14. Notes About Tools • VS.Net 2005 has its own performance tools which was demonstrated in discussion yesterday