The cost of MCF
-
The cost of MFC --------------- MFC dramatically simplifies Windows programming, but has some drawbacks, as reducing message processing performance. This doesn't make MFC unusable at all, but it's a good idea to keep in mind some numbers, to know how to improve an application, if necessary. I developed 3 simple test applications to test message performance. All they do is posts a message to it self 1000000 times, as shown below: void CMsgTestDlg::OnOK() { static unsigned uStatus = 0; if (uStatus < 1000000) { ++uStatus; PostMessage (WM_COMMAND, IDOK, 0); return; } CDialog::OnOK(); } The 3 applications are the following: 1) MFC - Dialog based App 2) Wizard generated API App 3) API App Here are the results: 1 MFC Application: 67 seg 2 Wizard Windows API: 12 seg 3 Windows API: 7 seg The low performance on app 2 is caused by a ‘LoadString’ in the beginning of the callback function.
-
The cost of MFC --------------- MFC dramatically simplifies Windows programming, but has some drawbacks, as reducing message processing performance. This doesn't make MFC unusable at all, but it's a good idea to keep in mind some numbers, to know how to improve an application, if necessary. I developed 3 simple test applications to test message performance. All they do is posts a message to it self 1000000 times, as shown below: void CMsgTestDlg::OnOK() { static unsigned uStatus = 0; if (uStatus < 1000000) { ++uStatus; PostMessage (WM_COMMAND, IDOK, 0); return; } CDialog::OnOK(); } The 3 applications are the following: 1) MFC - Dialog based App 2) Wizard generated API App 3) API App Here are the results: 1 MFC Application: 67 seg 2 Wizard Windows API: 12 seg 3 Windows API: 7 seg The low performance on app 2 is caused by a ‘LoadString’ in the beginning of the callback function.
Most MFC apps are user driven, it is still faster than the average user :-D Michael :-)
-
The cost of MFC --------------- MFC dramatically simplifies Windows programming, but has some drawbacks, as reducing message processing performance. This doesn't make MFC unusable at all, but it's a good idea to keep in mind some numbers, to know how to improve an application, if necessary. I developed 3 simple test applications to test message performance. All they do is posts a message to it self 1000000 times, as shown below: void CMsgTestDlg::OnOK() { static unsigned uStatus = 0; if (uStatus < 1000000) { ++uStatus; PostMessage (WM_COMMAND, IDOK, 0); return; } CDialog::OnOK(); } The 3 applications are the following: 1) MFC - Dialog based App 2) Wizard generated API App 3) API App Here are the results: 1 MFC Application: 67 seg 2 Wizard Windows API: 12 seg 3 Windows API: 7 seg The low performance on app 2 is caused by a ‘LoadString’ in the beginning of the callback function.
-
The cost of MFC --------------- MFC dramatically simplifies Windows programming, but has some drawbacks, as reducing message processing performance. This doesn't make MFC unusable at all, but it's a good idea to keep in mind some numbers, to know how to improve an application, if necessary. I developed 3 simple test applications to test message performance. All they do is posts a message to it self 1000000 times, as shown below: void CMsgTestDlg::OnOK() { static unsigned uStatus = 0; if (uStatus < 1000000) { ++uStatus; PostMessage (WM_COMMAND, IDOK, 0); return; } CDialog::OnOK(); } The 3 applications are the following: 1) MFC - Dialog based App 2) Wizard generated API App 3) API App Here are the results: 1 MFC Application: 67 seg 2 Wizard Windows API: 12 seg 3 Windows API: 7 seg The low performance on app 2 is caused by a ‘LoadString’ in the beginning of the callback function.
It would be an interesting test comparing with a WTL app... Crivo Automated Credit Assessment
-
The cost of MFC --------------- MFC dramatically simplifies Windows programming, but has some drawbacks, as reducing message processing performance. This doesn't make MFC unusable at all, but it's a good idea to keep in mind some numbers, to know how to improve an application, if necessary. I developed 3 simple test applications to test message performance. All they do is posts a message to it self 1000000 times, as shown below: void CMsgTestDlg::OnOK() { static unsigned uStatus = 0; if (uStatus < 1000000) { ++uStatus; PostMessage (WM_COMMAND, IDOK, 0); return; } CDialog::OnOK(); } The 3 applications are the following: 1) MFC - Dialog based App 2) Wizard generated API App 3) API App Here are the results: 1 MFC Application: 67 seg 2 Wizard Windows API: 12 seg 3 Windows API: 7 seg The low performance on app 2 is caused by a ‘LoadString’ in the beginning of the callback function.
Interesting info, thanks. As Micheal said earlier,t no usually an issue with GUI apps since most of the time it's idle anyway. My real concern with MFC is in its memory management scheme and how it handles handles, etc.
-
It would be an interesting test comparing with a WTL app... Crivo Automated Credit Assessment
WTL should be reasonably fast. Since WTL/ATL creates a message routine thunk for each window, there isn't the need to translate the HWND to a window class pointer. Then it just boilds down to how fast the monster "if" statement executes. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
WTL should be reasonably fast. Since WTL/ATL creates a message routine thunk for each window, there isn't the need to translate the HWND to a window class pointer. Then it just boilds down to how fast the monster "if" statement executes. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
Tim Smith wrote: Since WTL/ATL creates a message routine thunk for each window, there isn't the need to translate the HWND to a window class pointer. Then it just boilds down to how fast the monster "if" statement executes. I know, but it's still interesting to measure it, because it depends on how good the VC's code optimizer is in handling this "monster if". Crivo Automated Credit Assessment
-
Never had any problems over the past 9 years. Are you using "MCF" correctly?:~ Normski. - Professional Windows Programmer
I've been using MFC for the past 6 years, and I never had problems either. However, if you take a while to test the same code without using MFC you'll find some differences. I even had to programm MFC like classes, to compile a MFC program without MFC, so I know how they are implemented. To allow window classes inheritance you require virtual fuctions and some extra code, which make's the code more complex. For example, in a callback function, it's much easier to return 0 if the message is not processed, that to run some code to call derived message maps. This doesn't mean MFC isn't properly implemented, just that this "layering" has a cost, and it's not a bad idea to determine it.