[ACCEPTED]-Qt Application Performance vs. WinAPI/MFC/WTL/-qt

Accepted answer
Score: 39

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

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

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

Ease of programming / API: Qt is an absolute joy to 12 use, from its containers to its widget classes 11 to its modules. All the while making memory 10 management easy (QObject) system and mantaining 9 super performance. I've always written pure 8 win32 before this and I wil never go back. For 7 example, with the QtConcurrent classes I 6 was able to change a method invocation from 5 myMethod(arguments) to QtConcurrent::run(this, MyClass::myMethod, arguments)and with one single line a non-GUI heavy 4 processing method was threaded. With a QFuture and 3 QFutureWatcher I could monitor when the thread had ended 2 (either with signals or just method checking). What 1 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

Score: 24

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

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

To the point:

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

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

Score: 14

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

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

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

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

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

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

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

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

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

Score: 9

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

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

Score: 5

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

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

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

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

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

Score: 4

The overall program performance will of 10 course be up to you, but I don't think that 9 you have to worry about the UI. Thanks to 8 the graphics scene and OpenGL support you 7 can do fast 2D/3D graphics too.

Last but 6 not least, an example from my own experience:

  • Using Qt on Linux/Embedded XP machine with 128 MB of Ram. Windows uses MFC, Linux uses Qt. Custom user GUI with lots of painting, and a regular admin GUI with controls/widgets. From a user's point of view, Qt is as fast as MFC. Note: it was a full screen program that could not be minimized.

Edited after you have added more info: you 5 can expect a larger executable size (especially 4 with Qt MinGW) and more memory usage. In 3 your case, try playing with one of the IDEs 2 (e.g. Qt Creator) or text editors written in Qt and 1 see what you think.

Score: 3

I personally would choose Qt as I've never 7 seen any performance hit for using it. That 6 said, you can get a little closer to native 5 with wxWidgets and still have a cross-platform 4 app. You'll never be quite as fast as straight 3 Win32 or MFC (and family) but you gain a 2 multi-platform audience. So the question 1 for you is, is this worth a small trade-off?

Score: 0

My experience is mostly with MFC, and more 21 recently with C#. MFC is pretty close to 20 the bare metal so unless you define a ton 19 of data structure, it should be pretty quick.

For 18 graphics painting, I always find it useful 17 to render to a memory bitmap, and then blt 16 that to the screen. It looks faster, and 15 it may even be faster, because it's not worrying 14 about clipping.

There usually is some kind 13 of performance problem that creeps in, in 12 spite of my trying to avoid it. I use a 11 very simple way to find these problems: just 10 wait until it's being subjectively slow, pause 9 it, and examine the call stack. I do this 8 a number of times - 10 is usually more than 7 enough. It's a poor man's profiler but works 6 well, no fuss, no bother. The problem is 5 always something no one could have guessed, and 4 usually easy to fix. This is why it works.

If there are dialogs 3 of any complexity, I use my own technique, Dynamic Dialogs, because 2 I'm spoiled. They are not for the faint-of-heart, but 1 are very flexible and perform nicely.

More Related questions