The problem is, as we mentioned, we don't know what the program, the operating system or the hardware are exactly doing, and how much time each of them needs. So, we have to obtain this information somehow. The process of doing so is called profiling (creating the program's execution profile), and the tools we use to do that are called profilers. There are the following general approaches used to obtain performance data:

• Program instrumentation
• Runtime sampling
• Reading hardware or operating system counters

Let's look at each of these approaches in more detail.

Code instrumentation means adding additional code to our existing code base that will measure performance...

Now, as we already know what kinds of tools can be used for profiling, there will come a time when we will have to get our hands dirty and delve deeper into typical performance optimization work. For you to be able to reproduce it, we have to agree on the exact versions of our frameworks and tools. To make it short, we've decided on the following:

• Qt 5.9 LTE
• Windows 10
• Open source tools

This warrants some explanation, so read on. Let's start with the Qt framework.

Qt has many different versions and releases, but in this book, we have chosen to concentrate on the current (at the time of writing) long-term support (LTS) version, namely Qt 5.9—as it's the recent most stable release. Admittedly, a preview version of Qt 5.11 was present in the distribution, but we have, much to my regret, to ignore it.

Qt is a multiplatform framework; it...

On Linux Qt, Creator integrates with Valgrind's callgrind, which, alas, isn't available on Windows, so we have to look for other tools. Before we jump to the dedicated tools, let's discuss a very basic, little-known (as far as I can judge), but surprisingly effective, technique.

I call that technique the poor man's sampling technique. It is really simple. In its most basic form, you run a program in a debugger, stop it several times, and examine the call stack of the randomly chosen breaks. The idea is (as with sampling profilers) that the most-used function will show most often in the stack trace. Simple as it is, this quick technique will sometimes...

On Linux Qt, Creator integrates with Valgrind's memcheck, which, alas, isn't available on Windows, so we have to look for other tools. Before we jump into dedicated tools, however, let's first have a look at Windows system tools.

Unexpectedly, sometimes, much can be done just by using the old and trusty Process Explorer tool we introduced in the Widows system tools section earlier in this chapter. Let's discuss this with a real-life example.

In a project for one of my customers, there was a Qt application that suffered from timeouts when fetching frames from a camera. This is arguably a performance problem, so I started an investigation. As a first...

Is there too much complicated tooling for your taste? Don't panic; it doesn't always have to be a profiler; there is a set of simpler techniques, which oftentimes can prove to be quite sufficient.

Sometimes, the simplest thing we can do is just to add some printfs reporting times spend in critical parts of the code as debug outputs (that is, they will disappear in your Release build). This is the simplest form of manual instrumentation we can have—no sophisticated output formats; just simple human-readable log lines.

We can use it in two ways: first, when investigating some incumbent performance problem, and, second, for an overview of the general timing...

Besides the basic performance tools introduced so far, there are many more specialized tools we can use. We will introduce some of them in detail and only briefly mention some others.

On Linux, we have the excellent and widely known perftools suite for reading any imaginable kernel counters that might be relevant for performance. A little less well-known is the fact that Windows sports an equally excellent free performance toolset, namely the ETW and xperf tools, also known as the Windows Performance Toolkit (WPT). ETW traces can show the total system behavior, and that is how different processes influence themselves. We can use it in more difficult performance...

So, there was an awful lot of tools in this chapter, and then some more. What did we really learn from this chapter, besides a litany of tool names? Although it doesn't look like this at first glance, we indeed learned several important things, namely the following:

• What kinds of tools are programmers using for performance analysis?
• What platform, Qt version, and development environment will we be relying on in this book?
• What open source and free tools can we use on Windows in addition to Qt Creator?
• Much insight can be gained by relatively simple means.
• How to profile a QML application's CPU usage.
• How to profile a C++ (and mixed QML/C++) application's CPU usage.
• How to investigate memory usage and find memory leaks.

There are even more specialized performance tools you could use, so there's virtually no limit to the amount of data you can collect...

Here are some questions so that you can test your understanding of the topics in this chapter:

1. What does this mean: Apitrace preloads an instrumented implementation of OpenGL? Explain.
2. Isn't there a way to use the gprof after all?
3. How would you look for a lock convoy or a waiting chain causing your UI to stutter or, even worse, to freeze?
4. What is the difference between CPU Usage (Precise) and CPU Usage (Sampled) in ETW traces?

5. How would you find timers running amok or QML items accumulating video memory?
6. What can you do when your favorite open source performance is not supported by Qt Creator?
7. What is that thread and lock analysis feature some of the tools seem to have?
8. If you try to launch the example program directly or from an external CPU profiler, this won't work. Why not? How do you fix it?
9. If we don't use any custom ETW events in our program...