Alex Blasche

Qt QML Performance improvements in Qt 5.8.0

Published Wednesday March 8th, 2017
9 Comments on Qt QML Performance improvements in Qt 5.8.0
Posted in Performance, Qt Quick 2, Qt Quick Controls

Qt 5.8 benefited from significant performance efforts in Qt QML.  Some of us spent our entire time figuring out why things are slow and what could be done. This is a continued effort that pretty much started with the first Qt QML release and I don’t think will ever stop.  After a bit of deliberation we decided to make it a bit more obvious what kind of effort is ongoing. Due to this long standing effort we have accumulated a lot of performance tools and benchmarks from internal and external contributors. This enables us to put some hard figures to the general claim.

Startup Times

We compared general startup performance and ran graphical and non-graphical benchmarks for Qt 5.6.2 and Qt 5.8.0. As platforms we used Windows, Ubuntu, macOS and an iMX6 board (the only 32 bit architecture in the mix). The startup figures were taken for the following Qt configurations:

  • Qt 5.6.2
  • Qt 5.6.2 with commercial Qt Quick Compiler (qmlcompiler)
  • Qt 5.8.0 without QML caching
  • Qt 5.8.0 with QML caching (first startup)
  • Qt 5.8.0 with QML caching (subsequent starts too)

The last two configurations take into account that the cache is generated the first time an application is started and reused on subsequent runs. This assumes that the application does not change in between runs. The application under scrutiny was the Qt Quick Controls Gallery example. There is no particular reason for this selection other than that it is fairly large and has a lot of JavaScript in it. Here are the main take aways:

  • On macOS and Ubuntu, using caches gives the same results as using the qmlcompiler.
  • On iMX6, the caching is an actual improvement of 60% over the qmlcompiler.
  • On Windows, something other than the caching has regressed. Further checks resulted in QTBUG-59360.
  • The figures show the negative impact of initial cache generation (between 10% to 180%).

QML Benchmarks

While the startup figures above give a very detailed overview for a chosen application, it is likely to not match the next application. This is where more detailed benchmarks come in. The QML benchmarks can be categorized into two areas. The first category is related to QML binding performance (create, read & write different types of properties) and the second category measures graphical drawing performance. What can we see?

  • QML property reads and writes are on average 25% faster on desktop and 35% faster on iMX6
  • especially low end hardware benefits dis-proportionally from recent changes
  • some iMX6 tests have regressions. Looking at the code, in particular the use of C++11 atomics seems to have a bad influence (Qt 5.7 and later require a C++11 toolchain). A toolchain update might help.


We started these regular measurements in October and each round of improvements actually sparked new rounds as new issues appeared. It taught us that we have to run those tests more regularly or even automate them. For transparency purposes I attached a more detailed summary of the benchmarks results.

It is fair to say that there are still open issues which need further resolution (e.g. the startup performance on Windows or some of the discovered regressions in individual performance tests). Besides toolchain/compiler updates it clearly shows that more areas besides Qt QML need to be looked at.

To summarize we have a very broad improvement across the board in Qt 5.8.0 and the figures even validate some of our already ongoing plans such as shifting of the cache generation to compile time or improvements to the garbage collector. Stay tuned 😉

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Performance, Qt Quick 2, Qt Quick Controls


Sandro F says:

Hmmm…So is it still needed to use Qt Quick Compiler in commercial use with 5.8?

As we can see in benchmarks it is really difficult to know which mechanism should be used and how to find out which mechanism is used at all. For Android devices I do not find any benchmarks.

So if I disable Qt Quick Compiler with Qt 5.8 it will use the caching mechanism which is faster in a lot of cases? I really like to do your performance tests also for our application.


Erik Verbruggen says:

You can still use the Qt Quick Compiler with 5.8, but if you don’t want to, you don’t have to. It will help on first-start: creating the caches does take some time, and with the compiler those are not needed.

It is not hard to do such a test for your own application. The modifications I did to the qtquickcontrols gallery can be found at . It comes down to making sure the application quits after start-up, and then measuring the engine instantiation twice (first start includes plug-in loading and run static initialisers, while the second is “more purely” the application itself).

Nikita Krupenko says:

Cache generation during compile time would be really good.

Vincas says:

So instead of storing plain .qml files in resources AND cache generated at compile time, maybe it could store only the cached representations instead..?

Dimi says:

That would be marginally better, looks like it will solve QTBUG-58486 by avoiding it.

David says:

What kind of improvements can we expect for version 5.9

Alex Blasche Alex Blasche says: is probably the most noteworthy one.

Apart from that we continue the path we are walking already. We want to fix more performance bottle necks. As mentioned this is a never-ending story.

Dimi says:

Until QTBUG-58486 gets fixed, I cannot, in good conscience, distribute Qt software that employs the QML caching introduced in 5.8.

Dimi says:

And talking about “improving the garbage collector”, how about finally fixing the more than 1 year old untouched critical QTBUG-50319 which deletes objects that are still in use and crashes the application?

Commenting closed.

Get started today with Qt Download now