Presentation on theme: "Code Tuning Strategies and Techniques By: John Harrell."— Presentation transcript:
Code Tuning Strategies and Techniques By: John Harrell
Introduction 1960s computational limitations forced a focus on efficiency but in 1970s when limitations were reduced it was realized that code readability and maintainability was extremely difficult. 1980s brought again focus on efficiency while the 90s 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 isnt always the most important factor. Example, code that runs 50% faster wouldnt necessarily have better performance than code that requires 75% less user interaction
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 dont 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. Dont 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 Its 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 -Its 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, a=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 –Its 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 didnt 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 its 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 programs 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 isnt 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 wont start counting another program or count the time it used computing the time elapsed.
Iteration A single tuning doesnt 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 doesnt do anything revert back to original code
Techniques-Logic Make sure that a search algorithm stops when it finds what its looking for, or if its 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 – Dont execute the code until its 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 its 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