Qt Performance vs MFC Performance
Mike Vance
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)
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.
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?
Giovanni Dicanio
> Has anybody here determined how Qt applications compiled for Windows
> compare to MFC applications speed-wise? (Before I write further, I wish
The QT expert here is David Ching, so he could give you great advice.
My impression is that MFC apps tend to be faster than QT apps (but QT
apps tend to be faster than .NET apps).
An example of non-trivial QT app is Google Earth; I note that the menus
are displayed in a kind of "hesitant" way (not much, but some...), but
maybe it is just my impression?
Of course, if you need multiplatform portability, QT is a better choice.
Giovanni
Mike Vance
> apps tend to be faster than .NET apps).
Agreed. I am tired of all the people telling me about "magic CPU
cycles", wherein programming frameworks with lots of overhead are
"suppose" to be just as fast as C++ but obviously there is no way they
ever could be! They should just be honest and say other solutions are
"fast enough" for "most needs". Considering the average need for a
business is a lame front-end database, that doesn't say too much. I am
currently trying to determine how much slower Qt is, but it's hard
wading through the rhetoric.
> An example of non-trivial QT app is Google Earth; I note that the menus
> are displayed in a kind of "hesitant" way (not much, but some...), but
> maybe it is just my impression?
I forgot about that one. Perhaps I better go review the Qt apps page
and do a few more comparisons. Am trying to understand how that Qt
signal/slot 14 function call overhead stacks up compared to the MFC
message maps, especially when classes several descendants deep are
involved.
> Of course, if you need multiplatform portability, QT is a better choice.
> Giovanni
I still take pride in GUI snappiness. And multi-OS always seems to be a
dreamy topic that only materializes when the app is "watered down".
Potential multi-OS capability is an option that could be discarded, if
doing so would benefit the Windows users.
I guess I am waivering to the point that I will probably end up looking
at Codejock's June EOM update, at which point it will probably knock me
dead with its gorgeousness and sweep me off my feet. Still, it would be
nice if persons that have actually worked with both Qt and MFC on larger
projects could comment on the GUI speed of Qt. At least then I would
have something to write down in my notes for why I chose MFC over Qt.
Man, that Codejock ribbon is FAST...
Goran
Delphi 2 got out. I tried, and could not see, UI-wise or DB-access-
wise, noticeable difference between VCL (a toolkit written on a
variant of Pascal where practically all objects are allocated on the
heap) and MFC (4.0 at the time).
So...
Apart that Qt is more nicely designed than MFC, I can't say much about
Qt, but I am certain that if you can see the difference in performance
of UI widgets, it's __your fault__. Framework choice (especially for
native code) isn't a question of performance. That is already more
than good enough, and only your code will break it. At worst, you
should only look into things in Qt or <insert your toolkit here> that
don't use native widgets, or it's "fancy" features. That's where you
might find issues out of your control.
Goran.
P.S. I see that you downplay importance of multi-platform-ness of Qt.
If you don't really care about that, I'd say just take MFC. Not
because it's particularly good (it really ain't, especially when
looked at with today's eyes), but simply because it's ubiquitous; it
will indeed take you wherever you want to go.
David Ching
news:MPG.24917b848...@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.
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
Mike Vance
> of UI widgets, it's __your fault__.
Perhaps I take notice of these things moreso than most, but I believe
the average user still cares about a fast-responding interface.
Delphi 2009 includes a skinned ribbon that is completely deficient and
flickers like mad, because it's the same as the lousy TMS ribbon. The
DevExpress ribbon for Delphi is written a lot more carefully and looks
great. Delphi is a great tool. But I had to abandon it for this
project, which really requires speed. They neglected the Delphi
compiler too much; it stagnated. GNU/Intel/MS are competing against
each other for C++ optimization performance, and it's paying off.
That's why I am trying to determine if the Qt GUI "lagginess" I have
observed is inherit to the Qt system or just a side-effect how the
components are programmed.
> P.S. I see that you downplay importance of multi-platform-ness of Qt.
> If you don't really care about that, I'd say just take MFC. Not
> because it's particularly good (it really ain't, especially when
> looked at with today's eyes), but simply because it's ubiquitous; it
> will indeed take you wherever you want to go.
I was just hoping some experienced persons would have some facts to drop
into this thread.
Mike Vance
> * Qt performance is "very good"
> * C#/WinForms is "barely satisfactory, and at times, unsatisfactory"
Excellent input. Even simple observations like this are greatly
appreciated. I would agree with you on all three. There were some
statements that I ran across on the Internet that had me hoping that Qt
would actually EXCEED MFC in speed, but I guess anyone can make an
outlandish claim. MFC is so fast! You really notice the difference
when there are many rapid displays of data based on mouse hovering over
many items quickly. Speed is sexy!
> The Image Viewer demo may be relevant to your JPEG manipulation.
I will take a look at the demo. Somehow missed it.
> 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.
That is another factor weighing in favor of Codejock/MFC over Qt: I
feel a heavy bent toward the Office2007 look. I am really anxious to
see what changes Codejock makes to their skinning system EOM June 2009.
> 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.
The lack of variety of Qt components has boggled me. I thought it's
users would have been contributing a lot. Guess that's just within the
KDE realm.
I'm still researching the matter, but I will probably end up concluding
that this app -- which demands a lot in terms of performance -- would be
better off married to Windows both for an edge in performance and
appearance.
But I am still weighing things.
David Ching
> I'm still researching the matter, but I will probably end up concluding
> that this app -- which demands a lot in terms of performance -- would be
> better off married to Windows both for an edge in performance and
> appearance.
>
Your criteria fits the project where I used MFC with the CodeJock ribbon,
and I don't regret that choice. But developing MFC does take longer and
requires more effort than on the other frameworks, but it's probably not a
big negative for you.
-- David