Win32 Message Pump vs MFC Message Maps, which is faster? C++

Question

not from the ease of use, but from the performance point of view. are MFC message maps faster than a typical message pump?

Answer 1

MFC wraps the Win32 messaging, so if anything the MFC will be slightly slower. That said, if you're dealing with UI widgets performance is not a concern.

Answer 2

They can't possibly be faster since they're just a wrapper around normal Windows message pumps. That being said, they do help a lot with reflected messages and the custom controls' message pump encapsulation, and the overhead is negligible, so it could be worth it in the long run if you have a complicated UI project.

Answer 3

I have to disagree with the (so far) 2 other respondents who claim that the MFC message pump is less performant simply because it wraps plain old C message pumps: MFC uses a very different technique than a simple window proc containing a giant switch(message) statement.

The MFC message pump does indeed rely on the Win32 message loop (it has to). But the implementation is very different: Based on hooks, dispatching of messages handled internally by MFC rather than relying on the DispatchMessage() API.

MFC uses maps to match messages to handlers : O(log n). From that point of view, there could be cases where this is faster than a large and badly compiled switch(message) statement : O(n).

Also, it could be faster to identify the correct window object than DispatchMessage(), which we can't know for sure since Windows is not open source.

This is however not likely, especially taking the extra code into account, such as commands routing, idle processing and various corner cases handled by the MFC code... and the fact that compilers are smart enough to efficiently implement large switch() statements!

That being said, the performance hit has not been considered significant for over 15 years.

Answer 4

Serge Wrote:

The MFC message pump does indeed rely on the Win32 message loop (it has to). But the implementation is very different: Based on hooks, dispatching of messages handled internally by MFC rather than relying on the DispatchMessage() API.

I am not sure this is correct. If you look inside the MFC thrdcore.cpp file you will see this function:

  BOOL AFXAPI AfxInternalPumpMessage()
  {
     _AFX_THREAD_STATE *pState = AfxGetThreadState();


     .......... snip ...........


     // process this message
     if (pState->m_msgCur.message != WM_KICKIDLE 
         && !AfxPreTranslateMessage(&(pState->m_msgCur)))
     {
        ::TranslateMessage(&(pState->m_msgCur));
        ::DispatchMessage(&(pState->m_msgCur));
     }
     return TRUE;
  }

This function is called by the MFC PumpMessage function and as you can see it uses the Win32 DispatchMessage API just like any other Win32 application.