Qt Application Performance vs. WinAPI/MFC/WTL/

Question

I'm considering writing a new Windows GUI app, where one of the requirements is that the app must be very responsive, quick to load, and have a light memory footprint.

I've used WTL for previous apps I've built with this type of requirement, but as I use .NET all the time in my day job WTL is getting more and more painful to go back to. I'm not interested in using .NET for this app, as I still find the performance of larger .NET UIs lacking, but I am interested in using a better C++ framework for the UI - like Qt.

What I want to be sure of before starting is that I'm not going to regret this on the performance front.

So: Is Qt fast?

I'll try and qualify the question by examples of what I'd like to come close to matching: My current WTL app is Programmer's Notepad. The current version I'm working on weighs in at about 4mb of code for a 32-bit, release compiled version with a single language translation. On a modern fast PC it takes 1-3 seconds to load, which is important as people fire it up often to avoid IDEs etc. The memory footprint is usually 12-20 mb on 64-bit Win7 once you've been editing for a while. You can run the app non-stop, leave it minimized, whatever and it always jumps to attention instantly when you switch to it.

For the sake of argument let's say I want to port my WTL app to Qt for potential future cross-platform support and/or the much easier UI framework. I want to come close to if not match this level of performance with Qt.

Solution 1

Going native API is the most performant choice by definition - anything other than that is a wrapper around native API.

What exactly do you expect to be the performance bottleneck? Any strict numbers? Honestly, vague ,,very responsive, quick to load, and have a light memory footprint'' sounds like a requirement gathering bug to me. Performance is often overspecified.

To the point:

Qt's signal-slot mechanism is really fast. It's statically typed and translates with MOC to quite simple slot method calls.

Qt offers nice multithreading support, so that you can have responsive GUI in one thread and whatever else in other threads without much hassle. That might work.

Solution 2

Just chiming in with my experience in case you still haven't solved it or anyone else is looking for more experience. I've recently developed a pretty heavy (regular QGraphicsView, OpenGL QGraphicsView, QtSQL database access, ...) application with Qt 4.7 AND I'm also a stickler for performance. That includes startup performance of course, I like my applications to show up nearly instantly, so I spend quite a bit of time on that.

Speed: Fantastic, I have no complaints. My heavy app that needs to instantiate at least 100 widgets on startup alone (granted, a lot of those are QLabels) starts up in a split second (I don't notice any delay between doubleclicking and the window appearing).

Memory: This is the bad part, Qt with many subsystems in my experience does use a noticeable amount of memory. Then again this does count for the many subsystems usage, QtXML, QtOpenGL, QtSQL, QtSVG, you name it, I use it. My current application at startup manages to use about 50 MB but it starts up lightning fast and responds swiftly as well

Ease of programming / API: Qt is an absolute joy to use, from its containers to its widget classes to its modules. All the while making memory management easy (QObject) system and mantaining super performance. I've always written pure win32 before this and I wil never go back. For example, with the QtConcurrent classes I was able to change a method invocation from myMethod(arguments) to QtConcurrent::run(this, MyClass::myMethod, arguments)and with one single line a non-GUI heavy processing method was threaded. With a QFuture and QFutureWatcher I could monitor when the thread had ended (either with signals or just method checking). What ease of use! Very elegant design all around.

So in retrospect: very good performance (including app startup), quite high memory usage if many submodules are used, fantastic API and possibilities, cross-platform

Solution 3

Programmer's Notepad is an text editor which uses Scintilla as the text editing core component and WTL as UI library.

JuffEd is a text editor which uses QScintilla as the text editing core component and Qt as UI library.

I have installed the latest versions of Programmer's Notepad and JuffEd and studied the memory footprint of both editors by using Process Explorer.

Empty file:
- juffed.exe Private Bytes: 4,532K Virtual Size: 56,288K
- pn.exe Private Bytes: 6,316K Virtual Size: 57,268K

"wtl\Include\atlctrls.h" (264K, ~10.000 lines, scrolled from beginning to end a few times):
- juffed.exe Private Bytes: 7,964K Virtual Size: 62,640K
- pn.exe Private Bytes: 7,480K Virtual Size: 63,180K

after a select all (Ctrl-A), cut (Ctrl-X) and paste (Ctrl-V)
- juffed.exe Private Bytes: 8,488K Virtual Size: 66,700K
- pn.exe Private Bytes: 8,580K Virtual Size: 63,712K

Note that while scrolling (Pg Down / Pg Up pressed) JuffEd seemed to eat more CPU than Programmer's Notepad.

Combined exe and dll sizes:
- juffed.exe QtXml4.dll QtGui4.dll QtCore4.dll qscintilla2.dll mingwm10.dll libjuff.dll 14Mb
- pn.exe SciLexer.dll msvcr80.dll msvcp80.dll msvcm80.dll libexpat.dll ctagsnavigator.dll pnse.dll 4.77 Mb

The above comparison is not fair because JuffEd was not compiled with Visual Studio 2005, which should generate smaller binaries.

Solution 4

We have been using Qt for multiple years now, developing a good size UI application with various elements in the UI, including a 3D window. Whenever we hit a major slowdown in app performance it is usually our fault (we do a lot of database access) and not the UIs.

They have done a lot of work over the last years to speed up drawing (this is where most of the time is spent). In general unless you really do implement a kind of editor usually there is not a lot of time spent executing code inside the UI. It mostly waits on input from the user.

Solution 5

Qt is a very nice framework, but there is a performance penalty. This has mostly to do with painting. Qt uses its own renderer for painting everything - text, rectangles, you name it... To the underlying window system every Qt application looks like a single window with a big bitmap inside. No nested windows, no nothing. This is good for flicker-free rendering and maximum control over the painting, but this comes at the price of completely forgoing any possibility for hardware acceleration. Hardware acceleration is still noticeable nowadays, e.g. when filling large rectangles in a single color, as is often the case in windowing systems.

That said, Qt is "fast enough" in almost all cases.

I mostly notice slowness when running on a Macbook whose CPU fan is very sensitive and will come to life after only a few seconds of moderate CPU activity. Using the mouse to scroll around in a Qt application loads the CPU a lot more than scrolling around in a native application. The same goes for resizing windows.

As I said, Qt is fast enough but if increased battery draining matters to you, or if you care about very smooth window resizing, then you don't have much choice besides going native.

Since you seem to consider a 3 second application startup "fast", it doesn't sound like you would care at all about Qt's performance, though. I would consider 3 second startup dog-slow, but opinions on that vary naturally.

View more solutions

Comments

[Simon Steele]

Agreed, performance is often over-specified, and requirements mis-stated. However, how would you feel if Notepad took 10 seconds to load instead of less than 1, and whenever you restored it from minimized took 10 seconds to page back into memory? Some apps do warrant particular performance attention.

[Simon Steele]

Also, agreed that anything other than native API will be a wrapper, but there are fast wrappers and slow wrappers - Win Forms is a slow wrapper, WPF is a glacial wrapper. I'm looking for a wrapper that leaves the app a pleasure to use - frameworks should do their job and get out of my way :)

[Tadeusz A. Kadłubowski]

Well, Qt is good. Examples I use every day: Skype is fine performance-wise. Opera is one of the faster web-browsers. KDE is a pleasure to use, especially with hardware-supported graphical eye-candy. Expect performance similar to MFC, not to WPF. It's quite fast to develop with, so you'll have more time to hunt performance bottlenecks in your program.

[Simon Steele]

Updated the question to clarify my measurement points - thanks for the examples, that's useful.

[Nemanja Trifunovic]

I remember Scott Meyers was making some tests with a GUI application on Windows to test the ability of C++ compilers oto eliminate "template code bloat" and the machine code produced by the WTL version was practically the same as with "bare" WIn32 API. Can't find the article now, but try searching the internet.

[Harald Scheirich]

While the signal and slot mechanism might seem fast, it is definitely not light weight, one signal connected to one slot causes 3-4 if not more function calls, step through the thing and you will see.

[Simon Steele]

Probably worth it, thanks. I did consider wxWidgets, but I simply don't like the API - feels too much like MFC which I dislike with a passion.

[Simon Steele]

Thanks, that's a useful comparison!

[GorillaApe]

3 seconds are light speed. in .NET + wpf you may need half minute.. on some machines

[Ghita]

Why use QFuture/QtConcurrent run when you have all these in C++ 11 standard now (std::future, std::async, and if you want more low level std::thread)? You will stay as portable using QT as ever.

[Aktau]

My answer dates from a little bit more than a year ago, at which point C++11 wasn't even approved yet. Even now it is still not that widespread. The latest and greatest compilers support it decently but not everybody will be able to use that yet. Which is why these classes will stay relevant for quite some time and are in my opinion quite user-friendly. By the way if you go Qt you usually go all the way, which means leaving the STL by the side. But one can mix and match, of course.