C++ Qt 应用程序性能 vs. WinAPI/MFC/WTL/

Qt Application Performance vs. WinAPI/MFC/WTL/

提问by Simon Steele

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.

我正在考虑编写一个新的 Windows GUI 应用程序，其中一个要求是该应用程序必须响应迅速、加载速度快且内存占用少。

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.

我已经将 WTL 用于我根据此类需求构建的以前的应用程序，但是随着我在日常工作中一直使用 .NET，WTL 变得越来越痛苦。我对在这个应用程序中使用 .NET 不感兴趣，因为我仍然发现缺乏更大的 .NET UI 的性能，但我有兴趣为 UI 使用更好的 C++ 框架 - 比如 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?

所以：Qt 快吗？

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.

我将尝试通过我想接近匹配的示例来限定问题：我当前的 WTL 应用程序是Programmer's Notepad。我正在处理的当前版本对于 32 位发布编译版本，只有大约 4 mb 的代码，具有单一语言翻译。在现代快速的 PC 上，加载需要 1-3 秒，这很重要，因为人们经常启动它以避免 IDE 等。一旦您编辑了 64 位 Win7，内存占用通常为 12-20 mb尽管。您可以不间断地运行应用程序，将其最小化，无论如何，当您切换到它时，它总是会立即引起注意。

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.

为了争论起见，假设我想将我的 WTL 应用程序移植到 Qt，以获得潜在的未来跨平台支持和/或更简单的 UI 框架。如果不匹配 Qt 的这种性能水平，我想接近。

采纳答案by Tadeusz A. Kad?ubowski

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

根据定义，使用原生 API 是性能最高的选择——除此之外的任何东西都是原生 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 的信号槽机制真的很快。它是静态类型的，并通过 MOC 转换为非常简单的槽方法调用。

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.

Qt 提供了很好的多线程支持，因此您可以在一个线程中拥有响应式 GUI，而在其他线程中则可以轻松拥有响应式 GUI。那可能会奏效。

回答by Aktau

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.

只是加入我的经验，以防您仍然没有解决它或其他人正在寻找更多经验。我最近使用 Qt 4.7 开发了一个非常重的（常规 QGraphicsView、OpenGL QGraphicsView、QtSQL 数据库访问，...）应用程序，而且我也是性能的忠实拥护者。这当然包括启动性能，我喜欢我的应用程序几乎立即显示，所以我花了很多时间。

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).

速度：太棒了，我没有抱怨。我的重型应用程序需要在启动时实例化至少 100 个小部件（当然，其中很多是 QLabels）在一瞬间启动（我没有注意到双击和窗口出现之间有任何延迟）。

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

内存：这是不好的部分，根据我的经验，带有许多子系统的 Qt 确实使用了大量内存。再说一次，这确实对许多子系统的使用很重要，QtXML、QtOpenGL、QtSQL、QtSVG，你说出来，我用它。我当前的应用程序在启动时设法使用了大约 50 MB，但它启动速度快如闪电，响应也很快

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 nevergo 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 QFutureand QFutureWatcherI could monitor when the thread had ended (either with signals or just method checking). What ease of use! Very elegant design all around.

易于编程/API：Qt 使用起来绝对是一种乐趣，从它的容器到它的小部件类再到它的模块。同时使内存管理变得容易 (QObject) 系统并保持超级性能。在此之前我一直写纯win32，我永远不会回去。例如，使用 QtConcurrent 类，我能够将方法调用从 更改为myMethod(arguments)，QtConcurrent::run(this, MyClass::myMethod, arguments)并且只需一行即可将非 GUI 繁重的处理方法线程化。使用 aQFuture和QFutureWatcher我可以监视线程何时结束（使用信号或方法检查）。多么易用！非常优雅的设计。

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

所以回想起来：非常好的性能（包括应用程序启动），如果使用许多子模块，内存使用量会很高，出色的 API 和可能性，跨平台

回答by Cristian Adam

Programmer's Notepadis an text editor which uses Scintillaas the text editing core component and WTL as UI library.

Programmer's Notepad是一个文本编辑器，它使用Scintilla作为文本编辑核心组件，WTL 作为 UI 库。

JuffEdis a text editor which uses QScintillaas the text editing core component and Qt as UI library.

JuffEd是一个文本编辑器，它使用QScintilla作为文本编辑核心组件，Qt 作为 UI 库。

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

我已经安装了 Programmer's Notepad 和 JuffEd 的最新版本，并使用Process Explorer研究了这两个编辑器的内存占用。

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

空文件：
- juffed.exe 私有字节：4,532K 虚拟大小：56,288K
- pn.exe 私有字节：6,316K 虚拟大小：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

“wtl\Include\atlctrls.h”（264K，~10.000 行，从头到尾滚动了几次）：
- juffed.exe 私有字节：7,964K 虚拟大小：62,640K
- pn.exe 私有字节：7,480K 虚拟大小：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

全选 (Ctrl-A)、剪切 (Ctrl-X) 和粘贴 (Ctrl-V)
- juffed.exe 私有字节：8,488K 虚拟大小：66,700K
- pn.exe 私有字节：8,580K 虚拟大小：63,712钾

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

请注意，在滚动（Pg Down / Pg Up 按下）时，JuffEd 似乎比程序员的记事本消耗更多的 CPU。

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

组合的 exe 和 dll 大小：
- 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 libsexpnatag 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.

上述比较是不公平的，因为 JuffEd 不是用 Visual Studio 2005 编译的，它应该生成较小的二进制文件。

回答by Harald Scheirich

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.

我们多年来一直在使用 Qt，开发了一个大小合适的 UI 应用程序，其中包含 UI 中的各种元素，包括一个 3D 窗口。每当我们遇到应用程序性能的重大下降时，通常是我们的错（我们进行了大量的数据库访问）而不是 UI。

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.

在过去的几年里，他们做了很多工作来加速绘图（这是花费大部分时间的地方）。一般来说，除非你真的实现了一种编辑器，否则通常不会花很多时间在 UI 中执行代码。它主要等待用户的输入。

回答by rpg

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

程序的整体性能当然取决于你，但我认为你不必担心 UI。由于图形场景和 OpenGL 支持，您也可以快速制作 2D/3D 图形。

Last but 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.

• 在具有 128 MB 内存的 Linux/嵌入式 XP 机器上使用 Qt。Windows 使用 MFC，Linux 使用 Qt。带有大量绘画的自定义用户 GUI，以及带有控件/小部件的常规管理 GUI。从用户的角度来看，Qt 和 MFC 一样快。注意：这是一个无法最小化的全屏程序。

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

添加更多信息后进行编辑：您可以期待更大的可执行文件大小（尤其是 Qt MinGW）和更多的内存使用。在您的情况下，尝试使用其中一种 IDE（例如 Qt Creator）或用 Qt 编写的文本编辑器，看看您的想法。

回答by Ringding

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.

Qt 是一个非常好的框架，但存在性能损失。这主要与绘画有关。Qt 使用它自己的渲染器来绘制所有东西——文本、矩形，你可以命名它......对于底层的窗口系统来说，每个 Qt 应用程序看起来就像一个内部有大位图的单个窗口。没有嵌套的窗口，什么都没有。这有利于无闪烁渲染和对绘画的最大控制，但代价是完全放弃硬件加速的任何可能性。硬件加速现在仍然很明显，例如在用单一颜色填充大矩形时，窗口系统中经常出现这种情况。

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

也就是说，Qt 在几乎所有情况下都“足够快”。

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.

在 CPU 风扇非常敏感的 Macbook 上运行时，我主要注意到速度缓慢，并且在 CPU 适度活动几秒钟后就会恢复正常。使用鼠标在 Qt 应用程序中滚动比在本机应用程序中滚动更多地加载 CPU。调整窗口大小也是如此。

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.

正如我所说，Qt 足够快，但是如果增加电池消耗对您很重要，或者如果您关心非常平滑的窗口大小调整，那么除了原生之外，您别无选择。

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.

由于您似乎认为 3 秒的应用程序启动“快”，但听起来您根本不关心 Qt 的性能。我会考虑 3 秒启动狗慢，但对此的看法自然会有所不同。

回答by Shaun

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

我个人会选择 Qt，因为我从未见过使用它对性能造成任何影响。也就是说，您可以使用 wxWidgets 更接近本机，并且仍然拥有跨平台应用程序。你永远不会非常快直的Win32或MFC（家庭），但你获得一个多平台的受众。所以你的问题是，这是否值得一个小的权衡？

回答by Mike Dunlavey

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

我的经验主要是使用 MFC，最近使用 C#。MFC 非常接近裸机，因此除非您定义大量数据结构，否则它应该非常快。

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

对于图形绘制，我总是发现渲染到内存位图，然后将其 blt 到屏幕上很有用。它看起来更快，甚至可能更快，因为它不担心剪辑。

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

尽管我试图避免它，但通常会出现某种性能问题。我使用一种非常简单的方法来发现这些问题：等待直到它主观上变慢，暂停它，然后检查调用堆栈。我这样做了很多次 - 通常 10 次就足够了。这是一个穷人的分析器，但效果很好，没有大惊小怪，没有麻烦。问题总是没人能猜到，而且通常很容易解决。这就是它起作用的原因。

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

如果有任何复杂的对话框，我会使用我自己的技术Dynamic Dialogs，因为我被宠坏了。它们不适合胆小的人，但非常灵活且性能良好。

回答by Ian Moone

I once made an app to determine the "primeness" of a number (whether it was prime or composite).

我曾经制作了一个应用程序来确定一个数字的“质数”（无论是质数还是合数）。

I first attempted a Qt GUI, and it took 5 hours to return the answer for 1,299,827 on a computer with 8GB of RAM and an AMD 1090T @ 4GHz running no other foreground processes under Linux.

我第一次尝试使用 Qt GUI，在一台具有 8GB RAM 和 AMD 1090T @ 4GHz 的计算机上，花了 5 个小时才返回 1,299,827 的答案，Linux 下没有其他前台进程。

My second attempt used a QProcess of a console application that used the exact same code. On a laptop with 1.3GB of RAM and a 1.4GHz CPU, the response came with no perceivable delay.

我的第二次尝试使用了使用完全相同代码的控制台应用程序的 QProcess。在配备 1.3GB RAM 和 1.4GHz CPU 的笔记本电脑上，响应没有明显的延迟。

I will not deny, though, that it is far easier than GTK+ or Win32, and it handles things quite nicely, but separate intensive processing ENTIRELY from the GUI if you use it.

不过，我不会否认，它比 GTK+ 或 Win32 容易得多，并且处理得很好，但是如果您使用它，则将密集处理完全与 GUI 分开。