Code Tuning Strategies and Techniques

Code Tuning Strategies and Techniques By: John Harrell

Introduction • 1960’s computational limitations forced a focus on efficiency but in 1970’s when limitations were reduced it was realized that code readability and maintainability was extremely difficult. 1980’s brought again focus on efficiency while the 90’s let it relax again. • In 2000s efficiency is central again due to mobile device computational limitations.

Code Tuning • This is only one way to improve a programs performance. • There are often many different ways that will improve performance greater and require less time to implement.

Code Speed != Better Performance • How fast the code runs isn’t always the most important factor. • Example, code that runs 50% faster wouldn’t necessarily have better performance than code that requires 75% less user interaction

Performance and Code Tuning • Key Points • Program requirements • Program Design • Class and routine design • Operating-system interactions • Code compilation • Hardware • Code Tuning

Program Requirements • Make sure what is asked for is actually what is needed. • If a real time system is requested there might be parts that don’t need to be run in real time.

Program Design • Break Programs down into subsystems • Set performance goals for each system which makes it easier to see where the problems are occuring. • If the goals are explicit for each subsystem it will make it easier to program. • Don’t always look at the short term efficiency, and if the design is highly modular, a more efficient component can be used later.

Class and Routine Design • This includes choice of algorithms and data structures • Choosing the proper sort algorithm can make the difference in performance

Operating-System Interactions • Iteractions with files, devices or other thing involves the operating system. • Sometimes the operating system is used and it is unknown, keep in mind that it might be the operating system calls slowing the program down.

Code Compilation • Compilers have built in machine code optimization. • This may remove the need for any more optimization

Hardware • There are times when it might be more cost effective to purchase better hardware when the target user base is small. • This will also speed up other programs that are used on the same hardware.

Code Tuning • It is the practice of modifying code the operates correctly to make it run more efficiently. • This only involves modifying a few lines of code at a time. • It is not to be confused with redesign or other aforementioned improvements.

Code Tuning • It’s not the most effective, cheapest or easiest way to improve code, and it makes code more difficult to maintain. • It can be fun to do and satisfying • This ability is also seen as the “Holy Grail” for computer programmers.

Time Efficient Code Tuning • Barry Boehm reports that 80% of execution time comes from 20% of code • Donald Knuth goes on to state that 4% of code accounts for 50% of execution time. • It is important to determine which lines of code is the “4%” because then most optimization time can be spent on these lines of code.

False Notions • Less Code = Faster -It’s not always true that if less code is used then it must execute faster. -Example in the book was a small for loop. The for loop that sets a[I]= I is actually 50% slower than just declaring a[0]=0, a[1]=1, etc..

False Notions • Certain operations are probably faster • Everything will have an effect on performance, and when changes are made this can effect the code tuning. • Example, if a new complier that does better optimizations built it, it might not optimize code that already have specific optimizations.

False Notations • Optimize as you go • It’s not possible to detect bottlenecks until the code is complete. • Too much time can be spent on optimization and can detract from functionality. • Would you rather go back and tune 5% of code or readability work on 100%?

False Notions • A fast program is better than a correct one • A working program is always better than one that runs faster • Example, one project was almost scraped until someone came up with a new idea. At first he was mocked because his took 10 times longer but then he said well if mine didn’t work either it would work instantly.

When to Tune • If the code is complete and running correct but going slow, that would be a good time to tune.

Compiler Optimizations • Compare the strengths and weaknesses of different compilers. • Compilers can Optimize code better that is not optimized to begin with. • Some Compiler Optimizations offer up to a 40% increase

Bloat and Slowdowns • Input Output Operations • Always choose In-memory operations over disk if possible. • The difference in performance is very large between disk and memory speeds

Bloat and Slowdowns • System Calls • When you call the system you have to change states which can be costly • Writing custom services can be difficult but add much performance do to removal of unnecessary information

Interpreted Languages • These Languages are usually much slower because they have to process the programming language code before they can be executed.

Relative Performance Costs of Common Operations • With out being measured in the specific program being used it’s difficult to tell the performance of an operation. • Generally however there are just some slow operations. • Polymorphic routine calls • Division • Transcendental Functions (ie. Sine, Log)

Measurement • Measure the program to find the “hot spots” (code that is used the most). • This way you can focus on the hot spots with code tuning rather the entire program’s code. • Experience can not always be used with code tuning as a change in the compiler or library can heavily effect the way the code tuning works.

Measurements need to be precise • It isn’t good enough to count in your head to measure the programs performance. • If you make your own program use the CPU clock ticks used rather than time so it won’t start counting another program or count the time it used computing the time elapsed.

Iteration • A single tuning doesn’t usually produce the large amount of performance increase desired. • It takes a large number of small tunes to combine together and create a dramatic increase in performance.

Summary • Make sure the program is complete • If there is poor performance after that: • Measure to find “hot spots” • Determine what performance enhancements need to be made • Tune the bottleneck • Measure each tuning one at a time • If the tuning doesn’t do anything revert back to original code

Techniques-Logic • Make sure that a search algorithm stops when it finds what it’s looking for, or if it’s looking for more than one thing, stop looking for a part if it finds that part already • Add a break statement along with setting the Boolean to true.

Techniques-Logic • Order tests by frequency. If you have to test for a large amount of options, try to determine which option is going to be most common and put it at the front. • Also test different methods such as a case statement or large amounts of if else statements as different languages and compilers can vary.

Techniques- Loops • Lazy Evaluation – Don’t execute the code until it’s needed • Unswitching – make sure nested statements are properly nested or see if they need to be nested at all. • Jamming – make two loops into one

Techniques- Transformations • Use smaller data values when possible, ie use int instead of float • Use lower number of array dimensions • Use indexing and caching

Techniques - Expressions • Exploit Algebraic Identities • Use Strength reduction • Initialize at compile time • Pre-compute Results

Recording in a Low-Level Language • Sometimes it’s better to write code directly into a lower language but only do it for the very hot spots as this will take a lot of time. • Also make sure you have the code working in 100% of the high level lanauge

Questions?

Code Tuning Strategies and Techniques