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的性能不足，但我对使用更好的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应用程序是程序员的记事本。我正在开发的当前版本包含大约4mb的代码，用于32位的编译版本，使用单一语言翻译。在现代快速PC上，加载需要1-3秒，这很重要，因为人们经常启动它以避免ide等。你可以不间断地运行这个应用程序，让它最小化，不管怎样，当你切换到它时，它总是会立刻引起你的注意。
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的性能水平，我希望接近Qt。
9 个解决方案
#1
21
Going native API is the most performant choice by definition - anything other than that is a wrapper around native API.
根据定义，使用本机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.
性能瓶颈究竟是什么?严格的数字吗?坦白地说，很模糊，很敏感，很容易加载，并且有一个轻的内存占用”这听起来像一个需求收集bug。性能通常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将其转换为非常简单的slot方法调用。
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，而不必在其他线程中遇到太多麻烦。这可能会奏效。
#2
34
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.
如果你还没解决，或者其他人在寻找更多的经验，那就跟着我的经验走吧。我最近开发了一个非常重的应用程序(常规的QGraphicsView、OpenGL QGraphicsView、QtSQL数据库访问……)，具有Qt 4.7，我也非常注重性能。这当然包括启动性能，我喜欢我的应用程序立即出现，所以我在这上面花了很多时间。
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个小部件(当然，其中很多都是qlabel)，它在瞬间启动(双击和显示窗口之间没有任何延迟)。
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 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.
易于编程/ API: Qt是一种绝对的乐趣，从它的容器到它的小部件类到它的模块。同时使内存管理更简单(QObject)系统，性能更优。在此之前我一直写纯win32，我永远不会回去。例如，使用QtConcurrent类，我能够将方法调用从myMethod(参数)更改为QtConcurrent: run(这个，MyClass::myMethod，参数)，并使用一行代码线程处理非gui重载方法。通过QFuture和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和可能性，跨平台
#3
9
Programmer's Notepad is an text editor which uses Scintilla as the text editing core component and WTL as UI library.
程序员记事本是一个文本编辑器，使用闪烁作为文本编辑核心组件，WTL作为UI库。
JuffEd is a text editor which uses QScintilla as the text editing core component and Qt as UI library.
是一个文本编辑器，使用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.
我已经安装了最新版本的程序员记事本，并通过使用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 \包括\ atlctrls。h”(264K， ~10.000行，从头到尾滚动了几次):-鼓起来了。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
在选择all (Ctrl-A)之后，剪切(Ctrl-X)并粘贴(Ctrl-V) -放大。exe私有字节:8,488K虚拟大小:66,700K - pn。exe私有字节:8,580K虚拟大小:63,712K
Note that while scrolling (Pg Down / Pg Up pressed) JuffEd seemed to eat more CPU than Programmer's Notepad.
请注意，当滚动(Pg Down / Pg Up)的时候，juff似乎比程序员的记事本吃更多的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大小的组合:-放大。exe QtXml4。dll QtGui4。dll QtCore4。dll qscintilla2。dll mingwm10。dll libjuff。dll 14 mb - 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.
上面的比较是不公平的，因为juppy并没有与Visual Studio 2005编译，后者应该生成更小的二进制文件。
#4
7
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中执行代码不会花很多时间。它主要等待用户的输入。
#5
4
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，有大量的绘图;从用户的角度来看，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 editors written in Qt and see what you think.
在您添加了更多信息之后进行编辑:您可以期望更大的可执行文件大小(特别是使用Qt MinGW)和更多的内存使用。在您的情况下，尝试使用一个ide(例如Qt创建者)或用Qt编写的文本编辑器，看看您的想法。
#6
3
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上运行时，我通常会注意到它的运行速度非常慢。使用鼠标在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家第二创业公司速度很慢，但人们对此的看法自然不同。
#7
2
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 quite as 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，因为我从未见过使用Qt的性能受到影响。也就是说，通过wxWidgets，你可以更接近原生版，同时还可以有一个跨平台的应用。所以你的问题是，这是否值得一些小的交换呢?
#8
0
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 be faster, because it's not worrying about clipping.
对于图形绘制，我总是发现将它呈现到内存位图中，然后将其发送到屏幕上是很有用的。它看起来更快，甚至可能更快，因为它不用担心剪切。
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.
如果有任何复杂的对话，我使用我自己的技术，动态对话，因为我被宠坏了。它们不适合胆小的人，但它们非常灵活，性能很好。
#9
0
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，然后花了5个小时在一台拥有8GB RAM和4GHz的计算机上返回1,299,827的答案。
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内存和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，则完全独立于GUI。
#1
21
Going native API is the most performant choice by definition - anything other than that is a wrapper around native API.
根据定义，使用本机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.
性能瓶颈究竟是什么?严格的数字吗?坦白地说，很模糊，很敏感，很容易加载，并且有一个轻的内存占用”这听起来像一个需求收集bug。性能通常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将其转换为非常简单的slot方法调用。
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，而不必在其他线程中遇到太多麻烦。这可能会奏效。
#2
34
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.
如果你还没解决，或者其他人在寻找更多的经验，那就跟着我的经验走吧。我最近开发了一个非常重的应用程序(常规的QGraphicsView、OpenGL QGraphicsView、QtSQL数据库访问……)，具有Qt 4.7，我也非常注重性能。这当然包括启动性能，我喜欢我的应用程序立即出现，所以我在这上面花了很多时间。
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个小部件(当然，其中很多都是qlabel)，它在瞬间启动(双击和显示窗口之间没有任何延迟)。
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 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.
易于编程/ API: Qt是一种绝对的乐趣，从它的容器到它的小部件类到它的模块。同时使内存管理更简单(QObject)系统，性能更优。在此之前我一直写纯win32，我永远不会回去。例如，使用QtConcurrent类，我能够将方法调用从myMethod(参数)更改为QtConcurrent: run(这个，MyClass::myMethod，参数)，并使用一行代码线程处理非gui重载方法。通过QFuture和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和可能性，跨平台
#3
9
Programmer's Notepad is an text editor which uses Scintilla as the text editing core component and WTL as UI library.
程序员记事本是一个文本编辑器，使用闪烁作为文本编辑核心组件，WTL作为UI库。
JuffEd is a text editor which uses QScintilla as the text editing core component and Qt as UI library.
是一个文本编辑器，使用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.
我已经安装了最新版本的程序员记事本，并通过使用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 \包括\ atlctrls。h”(264K， ~10.000行，从头到尾滚动了几次):-鼓起来了。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
在选择all (Ctrl-A)之后，剪切(Ctrl-X)并粘贴(Ctrl-V) -放大。exe私有字节:8,488K虚拟大小:66,700K - pn。exe私有字节:8,580K虚拟大小:63,712K
Note that while scrolling (Pg Down / Pg Up pressed) JuffEd seemed to eat more CPU than Programmer's Notepad.
请注意，当滚动(Pg Down / Pg Up)的时候，juff似乎比程序员的记事本吃更多的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大小的组合:-放大。exe QtXml4。dll QtGui4。dll QtCore4。dll qscintilla2。dll mingwm10。dll libjuff。dll 14 mb - 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.
上面的比较是不公平的，因为juppy并没有与Visual Studio 2005编译，后者应该生成更小的二进制文件。
#4
7
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中执行代码不会花很多时间。它主要等待用户的输入。
#5
4
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，有大量的绘图;从用户的角度来看，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 editors written in Qt and see what you think.
在您添加了更多信息之后进行编辑:您可以期望更大的可执行文件大小(特别是使用Qt MinGW)和更多的内存使用。在您的情况下，尝试使用一个ide(例如Qt创建者)或用Qt编写的文本编辑器，看看您的想法。
#6
3
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上运行时，我通常会注意到它的运行速度非常慢。使用鼠标在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家第二创业公司速度很慢，但人们对此的看法自然不同。
#7
2
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 quite as 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，因为我从未见过使用Qt的性能受到影响。也就是说，通过wxWidgets，你可以更接近原生版，同时还可以有一个跨平台的应用。所以你的问题是，这是否值得一些小的交换呢?
#8
0
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 be faster, because it's not worrying about clipping.
对于图形绘制，我总是发现将它呈现到内存位图中，然后将其发送到屏幕上是很有用的。它看起来更快，甚至可能更快，因为它不用担心剪切。
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.
如果有任何复杂的对话，我使用我自己的技术，动态对话，因为我被宠坏了。它们不适合胆小的人，但它们非常灵活，性能很好。
#9
0
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，然后花了5个小时在一台拥有8GB RAM和4GHz的计算机上返回1,299,827的答案。
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内存和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，则完全独立于GUI。