This document discusses improving application performance. It begins by explaining why performance matters, such as making applications more attractive to users and helping users get things done more efficiently. It then discusses how to improve performance using the Theory of Constraints approach: 1) identify bottlenecks, 2) decide how to address bottlenecks, 3) optimize code, and 4) repeat until goals are met. Specific techniques discussed include profiling applications to find hot spots, optimizing at the design, source code, and compile levels, and considering trade-offs such as memory usage.

1. Agenda
• Why Performance Matters
• How You Can Improve Performance
3

2. Why Performance Matters
• Attractive to users
• Looks more professional
• Help you get things done more efficiently
• Keeps the flow
4

3. Why Performance Matters
• An example explains more than a thousand words
5

4. Why Performance Matters
• Performance is more important than ever before
– Dynamic user interfaces
• Qt Everywhere
– Desktop
– Embedded platforms with limited hardware
• We cannot just buy better hardware anymore
• Clock speed vs. number of cores
6

5. Why Performance Matters
• Not all applications can take advantage of
multiple cores
• And some will actually run slower:
– Each core in the processor is slower
– Most applications not programmed to be multi-
threaded
• Multi-core crisis?
7

6. Agenda
• Why Performance Matters
• How You Can Improve Performance
19

7. How You Can Improve Performance
• Theory of Constraints (TOC) by Eliyahu M. Goldratt
• The theory is based on the idea that in any complex
system, there is usually one aspect of that system that
limits its ability to achieve its goal or optimal
functioning. To achieve any significant improvement of
the system, the constraint must be identified and
resolved.
• Applications will perform as fast as their bottlenecks
20

8. Theory of Constraints
• Define a goal:
– For example: This application must run at 30 FPS
• Then:
1) Identify the constraint
2) Decide how to exploit the constraint
3) Improve
4) If goal not reached, go back to 1)
5) Done
21

9. Identifying hot spots (1)
• The number one and most important task
• Make sure you have plausible data
• Don't randomly start looking for slow code paths!
– An O(n2) algorithm isn't necessarily bad
– Don't spend time on making it O(n log n) just for fun
• Don't spend time on optimizing bubble sort
22

10. Identifying hot spots (1)
• “Bottlenecks occur in
surprising places, so
don't try second guess
and put in a speed hack
until you have proven
that is where the
bottleneck is” -- Rob Pike
23

11. Identifying hot spots (1)
• The right approach for identifying hot spots:
– Any profiler suitable for your platform
• Shark (Mac OSX)
• Valgrind (X11)
• Visual Studio Profiler (Windows)
• Embedded Trace Macrocell (ETM) (ARM devices)
• NB! Always profile in release mode
24

12. Identifying hot spots (1)
• Run application: “valgrind --tool=callgrind ./application”
• This will collect data and information about the program
• Data saved to file: callgrind.out.<pid>
• Beware:
– I/O costs won't show up
– Cache misses (--simulate-cache=yes)
• The next step is to analyze the data/profile
• Example
25

13. Identifying hot spots (1)
• Profiling a section of code (run with “–instr-atstart=no”):
#include<BbrValgrind/callgrind.h>
int myFunction() const
{
CALLGRIND_START_INSTRUMENTATION;
int number = 10;
...
CALLGRIND_STOP_INSTRUMENTATION;
CALLGRIND_DUMP_STATS;
return number;
}
26

14. Identifying hot spots (1)
• When a hot-spot is identified:
– Look at the code and ask yourself: Is this the right
algorithm for this task?
• Once the best algorithm is selected, you can exploit the
constraint
27

15. How to exploit the constraint (2)
• Optimize
– Design level
– Source code level
– Compile level
• Optimization trade-offs:
– Memory consumption, cache misses
– Code clarity and conciseness
28

16. Theory of Constraints
• Define a goal:
– For example: This application must run at 30 FPS
• Then:
1) Identify the constraint
2) Decide how to exploit the constraint
3) Improve
4) If goal not reached, go back to 1)
5) Done
65