Re: Qt Performance vs MFC Performance
"Mike Vance" <nospam@nospam.com> wrote in message
news:MPG.24917b84851bb153989684@news.microsoft.com...
Has anybody here determined how Qt applications compiled for Windows
compare to MFC applications speed-wise? (Before I write further, I wish
to apologize for being so engrossed in speed and hating wasted CPU
cycles; I hate sluggish GUIs and window refreshes. It disgusts me when
a window is resized and the contents get redrawn slow enough that the
user must pause for a second)
I have 15+ years of MFC experience and ~1 year Qt experience. The past year
I've been focusing more on Qt and not so much MFC. Prior to this past year,
I spent a few years in C# and WinForms. So perhaps my experience would be
useful to you.
When speaking of GUI performance:
* MFC performance is "excellent"
* Qt performance is "very good"
* C#/WinForms is "barely satisfactory, and at times, unsatisfactory"
Everything is double-buffered in Qt 4.5 (the latest version), so you won't
see any flicker. The brief hesitations of Qt I've encountered is when I
first access menu items that page in new parts of the app; when running in
the debugger, you can see debug messages that DLL's are being loaded. After
they're loaded, there are no significant hesitations anymore. The initial
hesitations are somewhat noticeable but are not large enough to be
distracting. Unlike with C# when the garbage collector runs, or assemblies
are loaded, there is significant and unpredictable delays that are very
distracting.
The project I am next working on will involve the presenting and
processing of thousands of JPEGs, as well as a myriad of other file
types. The main window's GUI will possess a ton of functionality and
have to refresh itself rapidly as information panes are updated to
reflect the different files hovered over. And yes, it would benefit
from multi-platform capability -- only if there were no visible
performance penalty.
My limited investigation so far turns up that "supposedly" there is
little or no speed difference between the two. I subscribe to the
Codejock MFC collection and I know for a fact that it's marvelous ribbon
and other components are up to the job. They are all very fast. Plus,
Codejock is going to be having a very nice update by the end of June
where purportedly the skinning system (which is already extremely fast)
is going to be improved quite a bit. Codejock is reluctant to say
everything because they do not want to tip off BCGSoft too much.
BCGSoft components had more flicker when I last reviewed them a few
months ago.
But would Qt stack up GUI refresh-wise? The Qt demos are too trivial to
assess this, so I will have to analyze the best thing I have to go by:
Opera. I use it all the time. It works great. But I notice something
that distresses me: If I run the cursor quickly over a long list of
tabs (or even not so quickly) I see that many tabs fail to receive the
properly hover-over highlighting. I am wary of the 14 function call
signal/slot overhead. I cannot determine if this failure to highlight
is an indicator of Qt slowness, or simply that a custom Opera control
has decided to not bother with the highlighting.
Have you really browsed through all the parts of Qt Demo? There are some
pretty CPU intensive graphics animations, etc. in there. The Image Viewer
demo may be relevant to your JPEG manipulation. After seeing all the
animation in Qt Demo, I would say Qt is a very performant framework.
I did not know Opera was written in Qt. Perhaps the hover-over highlighting
triggers only when the cursor is paused over the widget for a brief time, so
if you fly the mouse over the tabs, they will not be highlighted. I think
this behavior may be by design, but I'm not sure. Since the screen is being
updated (and via a double-buffer, at that), I scarcely think any number of
function calls (signal/slot overhead) will be noticeable. (When analyzing
signal/slot performance, you need to take into account whether the slot is
run on the same thread as the signal is emitted, because if it is the same
thread, it resolves to a simple function call, but if it is a different
thread, the parameters must be marshaled to the other thread and the slot
will be called when the events of that thread are processed, meaning it will
take longer than when both the signal and slot are on the same thread.) But
as I said, you can ignore any overhead caused by signals/slots compared to
other notification mechanisms.
I also used the CodeJock ribbon in one of my previous MFC projects. It does
indeed have excellent GUI performance, and is much better than BCGSoft's.
(MS sure made a mistake when they partnered with BCGSoft.) The thing about
the ribbon and other elements of the "MS Fluent UI" is that you need to
license the Fluent UI, and as part of the license agreement, I believe that
you are prohibited from using those UI elements on non-Windows platforms
(e.g. Mac and Linux). Therefore, I wouldn't expect to see any prewritten Qt
widgets for the ribbon and other Fluent UI elements, as it is not possible
to make them cross platform.
This to me is the worst part about Qt, and not just for the ribbon. The
available widgets are very limited compared to what are available in MFC,
and even worse, compared to what are available to the .NET frameworks
(WinForms, Wpf, Silverlight, etc.) Plus they look really ugly,
comparatively. For my current projects, this is not a concern, but it would
be if I were trying to make an Office-2007 style app.
This really is an age of programmer lies, where every system likes to
say it is "fast enough", when often CPU cycles are being wasted
terribly. That is why I need the advice of MFC programmers that
appreciate the worth of efficiency. Have any of you already compared Qt
with MFC and come to any conclusions? Are there any performance penalty
surprises out there that Qt fans are "hiding" or just do not wish to
talk about?
Qt is my favorite framework. Here are my rankings:
Qt
WinForms
MFC
WPF/Silverlight
ASP.NET
Both Qt and WinForms have a rich framework. Qt has better notifications
(signals/slots) and layout controls than anything else. WinForms has better
tools (IDE especially with Visual Assist X and Resharper plug-ins), but Qt
is no slouch with the Qt Visual Studio plug-in and Visual Assist X.
WPF/Silverlight and ASP.NET are not bad, but compared to the others require
a paradyme reset that is costly in terms of productivity, and for me is not
worth it.
Hope this helps. I would give Qt a try. It is very easy for an MFC
programmer to pick up. See my blog for tips on how this MFC programmer got
proficient with it:
http://dcsoft.com/community_server/blogs/dcsoft/archive/tags/qt/default.aspx
-- David