• 11
• 27
• 9
• 20
• 31

# lower CPU usage when resizing

This topic is 4573 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, I've developed a program and i've been trying to find the cause of a few problems, and i've discovered that it's giving me 100% CPU usage after about a minute of running. The program isnt really that complicated so it shouldnt be doing this. BUT i noticed by accident that if i click the edge of the window to resize but dont release, the usage drops to about 50%, then shoots back up when i let go. The window is a plain white window, no icons buttons or anything just a plain white background from a 'your first win32 app' example. I cant think why though. There has always been something wrong with my computer though, because the CPU temp jumps really high when under not huge amounts of work. But can anyone shed some light as to why holding on when resizing makes such a difference? Thanks.

##### Share on other sites
100% CPU usage is caused by your program not letting Windows to process other tasks. If you have an unlimited loop somewhere in your program (which is very likely since it's GUI), you should somewhere in the middle of the loop let Windows to handle other tasks, although however, a correct handling of your program messages should automatically handle this. If all else fails, try Sleep().

##### Share on other sites
There's the unlimited loop that uses PeekMessage within it, but there's no other work there. All the work done is from an interrupt timer called every 10milliseconds through timeSetEvent. So i would have thought i'm letting windows do everything it needs to since there is a message handler there?

##### Share on other sites
If there's an infinite loop that's always going around and around and around and around, without ever pausing, of course you're going to have 100% CPU utilization.

##### Share on other sites
yeah that does make sense, but its just this:

//Message handler:LRESULT CALLBACK WndProc(HWND hwnd,                         UINT msg,                         WPARAM wParam,                         LPARAM lParam){    // Process the message    switch (msg)    {        // Check for key press        case WM_KEYDOWN:        {            // Check for ESC key press            if (VK_ESCAPE == wParam)            {                // Destroy the window                DestroyWindow(hwnd);                break;            }        }break;        // Check for window closing        case WM_CLOSE:        case WM_DESTROY:        {            // Post a quit message on the queue            PostQuitMessage(0);            break;        }break;        default:        {            // Handle any unprocessed message            return DefWindowProc(hwnd, msg, wParam, lParam);        }break;    }    return(0);}// main loop:while (1)    {        // Check message queue        if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))        {            // Is it a quit message?            if (WM_QUIT == msg.message)                break;            // Translate and dispatch message            TranslateMessage(&msg);            DispatchMessage(&msg);        }    }

and this is what i've seen in pretty much every 'learn win32' book and tutorial. Is this the wrong way to do it?

##### Share on other sites
Consider a long, involved infinite loop to be like counting to a million, over and over and over again. Consider a tiny infinite loop to be like counting to three, over and over and over again. Now, tell me: Do you spend any less time counting when you count to three over and over again?

To fix this issue: Don't use PeekMessage. Use GetMessage, which will pause until a message is actually received. Of course, there are situations where you don't want to pause.

##### Share on other sites
PeekMessage checks to see if there is a message in the queue. It does not block, so whenever you do not have a pending message your message handling loop is equivalent to:
while (1)
{
}

which is a busy waiting loop in which the processor will continuously be checking that 1 is not false (which it isn't and never will be). The alternatives are to either use GetMessage instead of PeekMessage, which waits for a message in a non-busy manner before returning, or to add a call to Sleep in your loop to give up the processor to other processes for a time.

Enigma

##### Share on other sites
Beautiful....
GetMessage works perfectly. I guess peekmessage is for people who like the old way of doing things?
If you knew you would need complete processing power is it ok to use peekmessage or should you always be as friendly with windows as you can?

Thanks alot for your help guys.