Slow Qt application: how to commission a diagnosis and verify a fix

If a Qt application slows down or stops responding, start by reproducing a specific user task and measuring where the time goes. The findings will help you choose between changing data retrieval, interface behaviour or the way calculations are performed. When commissioning a fix, also agree how it will be checked on a computer and data representative of everyday use.

As a product owner, distinguish between two goals: the operation should finish sooner, and the application should respond while it runs. You can make the window usable without shortening the whole import. You can also shorten the import while leaving a period in which the user cannot do anything. Establish which problem is disrupting the team's work.

Describe a problem that can be reproduced

“The program is slow” is not enough to estimate a fix. Describe the task: which click starts the wait, what the user sees during it and how they know it has finished. Record the application version, operating system, computer, and the type and size of the data. Note whether the problem happens every time, on first launch or only after several hours of use.

If only some workstations are affected, comparing them is part of the diagnosis. A test on the developer's faster computer may not reproduce the reported issue. Likewise, a small test file is no substitute for the document that leaves an employee waiting. Test data should retain the characteristics relevant to the problem; take care not to remove those characteristics when anonymising it.

At this stage, you can commission a limited investigation. It should deliver a reproduced problem, measurements, an identified cause or a clear explanation of missing information, and a proposed scope for further work. This gives you a basis for a spending decision before the company commits to broadly “optimising the entire application”.

Find out what the application is waiting for

The developer should separate the time spent retrieving data, performing calculations and preparing the view. Profiling helps with this: it measures which parts of the program are doing work and how long they take. The Qt Quick documentation recommends profiling before choosing optimisations so that effort addresses the actual problem.

The tool needs to suit the application. QML Profiler in Qt Creator helps analyse interfaces built with QML and JavaScript, but it does not profile C++ code. A chart from this tool alone will not explain every delay in a Qt application. Ask for a finding tied to the reported task: what is slowing it down, and which measurement supports that conclusion?

If the program is waiting for an external system to respond, changing how buttons are drawn may not shorten that wait. If the data is already available but takes a long time to appear, the developer needs to investigate how the view is prepared. These are different scopes of work despite a similar symptom on screen. The conclusion should follow the evidence, rather than an assumption that Qt is to blame.

Check responsiveness separately

In Qt, lengthy work can be separated from the part of the program responsible for handling the interface. Displaying the result still needs to respect the rules for working with the interface on the main thread. This separation is described in the Qt documentation on threads and objects. As the buyer, you need to know how the application behaves while the task is running.

Simply postponing a heavy operation does not mean it will run in the background. QTimer schedules a call; it does not automatically move the work to another thread. If a demonstration shows a window appearing quickly and then freezing, check the full sequence of the task.

Agree whether the user should see progress, be able to cancel the task and safely close the window. You also need to specify what happens to partially completed changes. A “Cancel” button that leaves data in an unclear state is not a sufficient outcome for the fix.

Example: importing a file into a Qt application

Consider a hypothetical employee who selects a file to import, after which the window stops responding until the results appear. Before making changes, measure both the time until the data is displayed and the period during which the application does not respond to user actions. Also check whether repeating the same task changes its behaviour.

If the measurement shows that the import blocks the interface, the fix may involve separating that work and reporting progress and results. Acceptance checks should cover a completed import, an attempt to cancel and behaviour when the file causes an error. If retrieving data from a server turns out to be the cause, a different scope of work will be needed. This example illustrates the decision process; it is not a test result from a specific product.

Ultimately, compare the time taken, responsiveness and the correctness of the imported data. A window that appears sooner with an incomplete result does not meet the same requirement as a correctly completed operation.

Compare results under the same conditions

The report after the fix should record the application versions before and after the change, the computer, operating system, data and test procedure. Separate the first run from subsequent runs, when the program may use information it has already loaded. Repeat the scenario so that one favourable result does not stand in for an assessment of everyday use.

The running conditions should be comparable, including any measurement tools that are enabled. If the diagnosis requires a different program configuration, the developer should explain the difference and also check the release intended for users.

Measure the problem you set out to solve. For a slow startup, that means the time until the required task can be performed. For a frozen window, it means the response to user actions. If performance deteriorates during the day, it means behaviour after repeated operations. CPU and memory usage can help with the diagnosis, but neither replaces the outcome of the user's task.

Before deployment, also check functions that the fix may have affected, such as saving, filtering or printing. If the change affects data storage or the sequence of an operation, agree the conditions for returning to the previous version. The scope of these checks should reflect the change, rather than an arbitrary list of everything Qt can do.

What should the developer hand over?

Alongside the new program version, you need a short explanation of the cause, the changes made and the comparison results. It should be clear which conditions were tested, which limitations remain and who will monitor behaviour after deployment. Keep the scenario for checking later releases so that the same problem does not return unnoticed.

Approve the fix against the user requirement agreed in advance. A promise of a percentage speed increase, without specifying the task, data and measurement conditions, does not tell you whether an employee will be able to work more efficiently.