Qt应用程序性能与WinAPI/MFC/WTL /

Question

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

我已经将WTL用于我之前使用此类要求构建的应用程序,但由于我在日常工作中一直使用.NET,因此返回WTL变得越来越痛苦.我对这个应用程序使用.NET不感兴趣,因为我仍然发现较大的.NET UI缺乏性能,但我有兴趣为UI使用更好的C++框架 - 比如Qt.

在开始之前我想要确定的是,我不会在性能方面对此感到后悔.

那么:Qt快吗？

我将尝试通过我希望接近匹配的示例来限定问题:我当前的WTL应用程序是程序员的记事本.我正在研究的当前版本重约4mb的代码,用于32位版本的单一语言翻译版本.在现代快速PC上加载需要1-3秒,这很重要,因为人们经常启动它以避免IDE等.一旦你编辑了一个内存占用,通常在64位Win7上12-20 mb而.您可以不间断地运行应用程序,将其保持最小化,无论如何,当您切换到它时,它总会立即引起注意.

为了争论,我想说我想将我的WTL应用程序移植到Qt,以便将来可能的跨平台支持和/或更简单的UI框架.如果不与Qt的这种性能水平相匹配,我想接近.

Answer 1

只是根据我的经验,如果你仍然没有解决它或其他任何人正在寻找更多的经验.我最近用Qt 4.7开发了一个非常繁重的(常规QGraphicsView,OpenGL QGraphicsView,QtSQL数据库访问......)应用程序,而且我也是性能的坚持者.这当然包括启动性能,我喜欢我的应用程序几乎立即出现,所以我花了相当多的时间.

速度:太棒了,我没有抱怨.我的繁重的应用程序需要在启动时单独实例化至少100个小部件(授予,其中许多是QLabel)在瞬间启动(我没有注意到双击和窗口出现之间的任何延迟).

内存:这是不好的部分,根据我的经验,许多子系统的Qt确实使用了大量的内存.然后,这确实计入了许多子系统的使用,QtXML,QtOpenGL,QtSQL,QtSVG,你给它命名,我用它.我目前在启动时的应用程序设法使用大约50 MB,但它启动快速闪电并快速响应

易于编程/ API:Qt使用起来非常快乐,从容器到小部件类到模块.一直使内存管理容易(QObject)系统和保持超级性能.在此之前我总是写纯win32,我永远不会回去.例如,与QtConcurrent类我能够从改变一个方法调用myMethod(arguments),以QtConcurrent::run(this, MyClass::myMethod, arguments)及具有一个单线非GUI的繁重处理方法螺纹.使用a QFuture和QFutureWatcher我可以监视线程何时结束(使用信号或只是方法检查).什么是易用性!非常优雅的设计.

所以回想起来:非常好的性能(包括app启动),如果使用了很多子模块,内存使用率非常高,API和可能性非常好,跨平台

Answer 2

根据定义,使用本机API是最高性能的选择 - 除此之外的任何东西都是本机API的包装器.

您期望什么是性能瓶颈？任何严格的数字？老实说,模糊,响应迅速,加载速度快,内存占用少,"听起来像是一个需要收集bug的要求.绩效往往过于明确.

要点:

Qt的信号槽机制非常快.它是静态类型的,并使用MOC转换为非常简单的插槽方法调用.

Qt提供了很好的多线程支持,因此您可以在一个线程中使用响应式GUI以及其他线程中的任何其他线程,而不会有太多麻烦.那可能有用.

Answer 3

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

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

我安装了最新版本的Programmer's Notepad和JuffEd,并使用Process Explorer研究了两个编辑器的内存占用量.

空文件:
- juffed.exe私有字节:4,532K虚拟大小:56,288K
- pn.exe私有字节:6,316K虚拟大小:57,268K

"wtl\Include\atlctrls.h"(264K,~10,000行,从头到尾滚动几次):
- juffed.exe私有字节:7,964K虚拟大小:62,640K
- pn.exe私有字节:7,480K虚拟尺寸:63,180K

选择全部(Ctrl-A),剪切(Ctrl-X)和粘贴(Ctrl-V)之后
- juffed.exe私有字节:8,488K虚拟大小:66,700K
- pn.exe私有字节:8,580K虚拟大小:63,712 ķ

请注意,在滚动时(按下Pg Down/Pg Up),JuffEd似乎比Programmer的记事本吃掉了更多的CPU.

组合的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 libexpat.dll ctagsnavigator. dll pnse.dll 4.77 Mb

上面的比较是不公平的,因为JuffEd没有用Visual Studio 2005编译,它应该生成更小的二进制文件.

Answer 4

我们多年来一直在使用Qt,在UI中开发包含各种元素的大尺寸UI应用程序,包括3D窗口.每当我们遇到应用程序性能大幅下降时,通常是我们的错(我们做了很多数据库访问)而不是UI.

他们在过去几年里做了很多工作来加速绘图(这是大部分时间花在的地方).一般情况下,除非你真的实现了一种编辑器,否则在UI中执行代码的时间并不长.它主要等待用户的输入.

Answer 5

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

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

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

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

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