• Advertisement
Sign in to follow this  

MFC

This topic is 4483 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

First off, I know some people hate MFC with a passion, and I know some of these people. Please try to put aside those feelings for the following question. It is said that trying to do, say a game editor or other real-time tool such as that will incur a huge speed penalty as a result of simply using MFC (>20%). At first glance, I'd like to call BS on this. A little over a year ago I was working on an RPG. The level editor was written in MFC as well as some other tools, and if I remember right they all ran at roughly the same speed as the game itself. Unfortunately it would require more work than I have time for to get all these tools and game compiling again to see for sure, so I'm asking here for other opinions. Obviously, it was necessary to override the default message pump that MFC implements, because of its use of GetMessage blocking, but after that there seemed to be little overhead in using MFC. So does anyone have any additional info? Does MFC really have some magical >20% performance penalty(provided you make necessary modifications to the message pump?) [Edited by - DrEvil on October 12, 2005 6:59:34 AM]

Share this post


Link to post
Share on other sites
Advertisement
MFC does introduce some overhead as compared to a raw Win32 application. And if your application does very little, then yes a 20% or more performance penalty can be seen. If your application does a lot then the overhead becomes negligible. This is assuming a competent MFC programmer. An incompetent MFC programmer can accidently introduce a whole lot of unnecessary overhead which may seem like it's MFC's fault, but is actually a problem with misusing MFC.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
MFC does introduce some overhead as compared to a raw Win32 application.


But you know what the overhead is not any more, and likely less, than writing your own functionally equalvalent GUI framework. Also, MFC is faster than Qt for sure, and probably wxWidgets (why would wx be faster??). Contrary to popular belief, MFC does not even use virtual functions for its message mapping, so you don't even have the overhead of calling virtual functions for messages.

I've used MFC since VC 1.5 back in the early 90s. Sure we've had some rough spots. Maybe the docs could be a little better, perhaps CDockBar could be exposed, the tool bar could be more robust, but the bottom line is that once you become more familar with it, the frustration of using it will certainly go away. Make no mistake about it, you'll end up writing your own control bars, but the framework is already there to write them and get them to work... and its EASY to make them.

Admittedly, you've got to learn how subclassing and serialization work to really take advantage of it. Once you learn the internals you'll never want to switch.

MFC is an awsome toolkit and it doesn't get nearly the credit it deserves. I'm tired of pansy-ass programmers dissing it because "they don't get it". Well I tell them, "hey if you want to be hand held go use C#, and take the 50% to 80% performance hit on your UI."

Share this post


Link to post
Share on other sites
Quote:
Original post by DrEvil
Do you know offhand some examples of the overheads involved?


Take window creation. MFC creates a CBT hook with a state block that last the duration of the entire thread. It maintains quite a bit of information in the thread local storage, and when CWnd::CreateEx() is called, the address of the CWnd is placed in the TLS. Also stored is a per thread HWND to CWnd handle map.

Now when a message arrive directed at a MFC window, it goes from AfxWndProcBase() to AfxWndProc(), which then looks up the HWND from the window handle map. AfxWndProc() then calls AfxCallWndProc() which replaces the HWND with the CWnd *, which then calls CWnd::WindowProc(), which calls CWnd::OnWndMsg() when then takes the message, cracks it open, and forwards to call to the correct handler.

Share this post


Link to post
Share on other sites
Quote:
Original post by krum
But you know what the overhead is not any more, and likely less, than writing your own functionally equalvalent GUI framework.

I'm pretty sure I could write an equivalent GUI framework that didn't need to do a linear time lookup to connect HWND handles to class pointers that had a minimum of five function calls for every windows message recieved that didn't have a redundant RTTI implementation or require a per thread initialization function.

Or I could just use ATL instead.

Or I could realize that the speed of the GUI framework is irrelevant since if GUI actions are taking a signficant amount of time in your application, then it probably means that your application isn't doing very much.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
I'm pretty sure I could write an equivalent GUI framework that didn't need to do a linear time lookup to connect HWND handles to class pointers


MFC does not do a linear lookup. It uses a hash table.

Share this post


Link to post
Share on other sites
A hash table with open chaining that generates an absurdly large number of collisions when using HWND values as a key. Which degenerates into a linear search.

Share this post


Link to post
Share on other sites
Quote:
Original post by krum
MFC is an awsome toolkit and it doesn't get nearly the credit it deserves. I'm tired of pansy-ass programmers dissing it because "they don't get it". Well I tell them, "hey if you want to be hand held go use C#, and take the 50% to 80% performance hit on your UI."


Please tell me that was a joke...

Share this post


Link to post
Share on other sites
DrEvil: I hope the message you got from all of this is that you should use MFC for your tool, right? [smile] Because as far as getting a Windows GUI application up and running quickly, MFC is great. The time you save in development, frustration, and avoidance of mundane Windows tasks is well worth any small hit in speed that doesn't matter much anyway in this case (unless you're developing a real-time application which most classes of level-editor-related tools are not).

Share this post


Link to post
Share on other sites
I just wanted clarification that I had the correct idea that there is nowhere near the level of performance hit that some people I know are claiming. I had brought up MFC as an alternative to our own win32 wrappings which are essentially doing very similar things.

I understand there are overheads to anything that wraps underlying functionality, so I didn't expect the answer to be no overhead.

You're right though, I really like MFC for its speed and ease of use. With minor mods to the message pump it was easily capable of powering the GUI for the world editor and several other editors for an RPG I worked on a while back, at very near the performance of the game itself.

Share this post


Link to post
Share on other sites
It's almost impossible to make a general case analysis of MFC's performance or viability as compared to another framework (or just raw Win32). The problem is that not only does the specific tasks of the application affect its performance, but many times in the Real World these performance comparisons alone are a moot point. If a game development studio needs to get a tool up and running for their artists/designers in the shortest possible time, then they're going to go with whatever solution leverages ease of programmability, functionality, maintainability, speed, and development time, and it just so happens that MFC is good in most those areas. Of course it's not a general solution to all your Windows application needs. But you simply have to determine what your real goals are. If you have the time to sit down and write your own Win32 framework, that's fine. If you have to sit down and write raw Win32 code because your application requires lighting performance, that's fine. Overall, I just wish people (not necessarily you) would start seriously considering the tools available and stop worrying about random - often irrelevant - benchmarks pulled out of thin air.

Share this post


Link to post
Share on other sites
Properly setup the only overhead MFC will introduce is the memory needed to load the required DLLs, which can be substantial if you have limited memory ( which is rarely the case ). Beyond that the performance hit is negligeble, like all code if you write bad MFC code it will run badly.

I have written a number of game tools using MFC and the only problem I have had is using windows timers to trigger rendering, they are horribly inaccurate. More often then not the tool is dealing with a very small subset of game functionality and doesnt require every last drop of performce ( ie, UI editor, effect editor, sound editor... ). Even if you are very abmitious and want to do an editor that is basically running the entire game and doing stuff ( ie neverwinter nights ) the UI will not being doing anything unless touched and unless you have controls updating all the time ( histograms, charts, ect ) MFC will not being doing anything at all.

Jason

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
MFC is still ok to use in my books, as when I use it, I only
use it as a Windows class wrapper. There's really no noticable
performance loss when used this way. Windows receives messages
by the 100's, and when done it spends the 99.99% rest of its
time idling away. Now using the DocView... that's a diffent story.
I think DocView is why most people hate MFC with a passion,
but other than that it's not that bad at all. OWL was nice
back in its day, but when Borland introduced their DocView,
OWL died.

Share this post


Link to post
Share on other sites
I'm not looking for useless benchmarks. Just data that can possibly help me provide viable information to some of these people who are insisting that simply using MFC is a, and I quote "20% performance hit if you're lucky", which is not the case. It's really aggravating when people buy into such nonsense like this, especially when it hurts the rest of the team by these select few ruining the opportunity to use some software because of such misconceptions, which leaves the team using and supporting some (often) inferior alternative that is more trouble than its worth, all in the name of counting CPU cycles.

I understand the hatred for DocView and some of the more complex app types, I don't like them much either. In my experience, we did all of our editors as a dialog app, which kept things very simple, and never caused any performance issues(and was much preferable over straight Win32). Of course the other nice thing about MFC or some of the other established GUI toolkits is that it is often relatively easy to find custom widgets online, which is something you don't get from a custom wrapper.

Thanks again for the input everyone.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement