Re: XP increased processor utilization

On Mon, 14 Apr 2008 08:45:01 -0700, FLevel8 <FLevel8@nospam.nospam> wrote:


I don't know how many windows you have, but the message you linked to
talked about several hundred. The "excessive-mouse" guy is implicitly doing
a lot of SendMessage in the idle time handler, and it appears to me that
::SendMessage is a lot less efficient in XP SP2 than in Vista (and
presumably 2K as well). After a lot of experimenting to rule out slowness
in things like the SendMessageToDescendents looping, I finally ended up
with:

BOOL CMdi_btnApp::OnIdle(LONG lCount)
{
#if 1
    if (CWnd* pMainWnd = AfxGetMainWnd())
    {
        static HWND hWnd;
        if (hWnd == 0)
        {
            static CButton btn;
            btn.Create(_T("1"), BS_PUSHBUTTON | WS_VISIBLE,
                    CRect(0, 0, 100, 100), pMainWnd, 2000);
#if 1 // A
            hWnd = btn.UnsubclassWindow();
#else
            hWnd = btn.m_hWnd;
#endif
        }
        if (hWnd)
        {
#if 1 // B
            static int n;
            for (int i = 0; i < 1000; ++i)
                SendMessage(hWnd, WM_NULL, 0, 0);
            // TRACE(_T("Count = %d\n"), ++n);
#endif
        }
    }
    return false;
#else
    return CWinApp::OnIdle(lCount);
#endif

}

This does not call CWinApp::OnIdle, but it does call SendMessage 1000 times
on a single window, which is comparable to what the "excessive-mouse" guy
is doing implicitly with his hundreds of windows. Here are my results,
which I obtained by rapidly moving the mouse over the MDI child window for
approximately 15 sec and viewing the CPU utilization in the Process
Explorer Performance Graph tab, which belongs to the individual process
properties dialog box (the TRACE ensured I was comparing a like number of
OnIdle calls and was disabled thereafter):

1. (A) and (B) active:
XP SP2: 3.5%
XP SP2 + Themes: 8%
Vista SP1: 1%

2. (A) inactive, (B) active:
XP SP2: 9%
XP SP2 + Themes: 12%
Vista SP1: 4%

3. (A) inactive, (B) inactive:
XP SP2: 0%
XP SP2 + Themes: 0.5%
Vista SP1: 0%

Case (1) times SendMessage to a window not mapped to an MFC window, and it
is clear that this uses significantly more CPU in XP. Turning themes on
makes it even worse.

Case (2) times SendMessage to a window that is mapped to an MFC window, and
while MFC's message map processing imposes a substantial increase in CPU
utilization, Vista is still beating XP by a large margin.

Case (3) simply disables everything.

Your program is most like Case (2).

To try to quantify the difference in SendMessage efficiency, I created a
program to time a tight SendMessage loop. My results were:

XP SP2: 9.73e+005 SendMessage/sec
XP SP2 + Themes: 9.64e+005 SendMessage/sec
Vista SP1: 4.21e+006 SendMessage/sec

So, it would seem Vista is about 4x faster at SendMessage than XP. Here's
the program (derived from Raymond Chen's "scratch" program):

#define STRICT
#include <windows.h>
#include <tchar.h>

#include <stdio.h>
#include <time.h>

HINSTANCE g_hinst; /* This application's HINSTANCE
*/
HWND g_hwndChild; /* Optional child window */

/*
 * Window procedure
 */
LRESULT CALLBACK
WndProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uiMsg) {
    }

    return DefWindowProc(hwnd, uiMsg, wParam, lParam);
}

BOOL
InitApp(void)
{
    WNDCLASS wc;

    wc.style = 0;
    wc.lpfnWndProc = WndProc;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = 0;
    wc.hInstance = g_hinst;
    wc.hIcon = NULL;
    wc.hCursor = LoadCursor(NULL, IDC_ARROW);
    wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
    wc.lpszMenuName = NULL;
    wc.lpszClassName = _T("Scratch");

    if (!RegisterClass(&wc)) return FALSE;

    return TRUE;
}

int WINAPI WinMain(HINSTANCE hinst, HINSTANCE hinstPrev,
                   LPSTR lpCmdLine, int nShowCmd)
{
    MSG msg;
    HWND hwnd;

    g_hinst = hinst;

    if (!InitApp()) return 0;

        hwnd = CreateWindow(
            _T("Scratch"), /* Class Name */
            _T("Scratch"), /* Title */
            WS_OVERLAPPEDWINDOW, /* Style */
            CW_USEDEFAULT, CW_USEDEFAULT, /* Position */
            CW_USEDEFAULT, CW_USEDEFAULT, /* Size */
            NULL, /* Parent */
            NULL, /* No menu */
            hinst, /* Instance */
            0); /* No special parameters */

        ShowWindow(hwnd, nShowCmd);

const int N = 50*1000*1000;
Sleep(5000);
clock_t t0 = clock();
for (int i = 0; i < N; ++i)
   SendMessage(hwnd, WM_NULL, 0, 0);
clock_t t1 = clock();
double sec = double(t1-t0)/CLOCKS_PER_SEC;
TCHAR buf[100];
_stprintf(buf, _T("%.2e SendMessage/sec (%.2f sec)"),
   N/sec, sec);
MessageBox(0, buf, 0, 0);

    return 0;
}


Certainly, it can be postponed, but as you realize, parts of the UI that
depend on idle time processing due to WM_MOUSEMOVE might not update
properly. To be safer, and if your UI isn't suffering any ill effects, you
might allow (say) every tenth WM_MOUSEMOVE to invoke idle processing.


Leaking temporary objects is not a good plan. Definitely don't do that.

--
Doug Harrison
Visual C++ MVP