Win32 Message Pumps против MFC Message Maps, что быстрее? C ++

Question

не с точки зрения простоты использования, а с точки зрения производительности. карты сообщений MFC быстрее, чем типичный насос сообщений?

Answer 1

Они не могут быть быстрее, потому что они просто обертка вокруг обычных насосов сообщений Windows. При этом они очень помогают с отображаемыми сообщениями и инкапсуляцией сообщений пользовательских элементов управления, и издержки незначительны, так что в долгосрочной перспективе это может стоить того, если у вас сложный проект пользовательского интерфейса.

Answer 2

MFC переносит обмен сообщениями Win32, так что в любом случае MFC будет немного медленнее. Тем не менее, если вы имеете дело с производительностью виджетов пользовательского интерфейса, это не проблема.

Answer 3

Я должен не согласиться с (до сих пор) 2 другими респондентами, которые утверждают, что насос сообщений MFC менее производительный просто потому, что он оборачивает простые старые насосы сообщений C: MFC использует совершенно другую технику, чем простой процесс окна, содержащий гигантский оператор коммутатора (сообщения).

Насос сообщений MFC действительно полагается на цикл сообщений Win32 (он должен). Но реализация очень отличается: на основе хуков, диспетчеризация сообщений обрабатывается внутри MFC, а не полагается на API DispatchMessage ().

MFC использует карты для сопоставления сообщений с обработчиками: O (log n). С этой точки зрения, могут быть случаи, когда это быстрее, чем большой и плохо скомпилированный оператор переключателя (сообщения): O (n).

Кроме того, может быть быстрее определить правильный объект окна, чем DispatchMessage (), который мы не можем знать наверняка, поскольку Windows не является открытым исходным кодом.

Это, однако, маловероятно, особенно принимая во внимание дополнительный код, такой как маршрутизация команд, обработка в режиме ожидания и различные угловые случаи, обрабатываемые кодом MFC ... и тот факт, что компиляторы достаточно умны, чтобы эффективно реализовывать большие switch() заявления!

При этом снижение производительности не считается значительным уже более 15 лет.

Answer 4

Серж написал:

Насос сообщений MFC действительно полагается в цикле сообщений Win32 (он должен). Но реализация очень разные: на основе крючков, диспетчеризация сообщений, обрабатываемых внутри MFC вместо того, чтобы полагаться на DispatchMessage () API.

Я не уверен, что это правильно. Если вы загляните внутрь файла MFC thrdcore.cpp , вы увидите эту функцию:

  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;
  }

Эта функция вызывается функцией MFC PumpMessage и, как вы можете видеть, использует API Win32 DispatchMessage , как и любое другое приложение Win32.