• Advertisement
Sign in to follow this  

MFC

This topic is 4574 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
Sign in to follow this  

  • Advertisement