The window callback function

[oex]

I see now that I should have used a different way of controlling the conditional assembly.

:lol I thought I saw a bug in my interpretation but I couldnt find it

You would also have to remove peekmessage to time both of them individually. You include peekmessage when getqueuestatus runs. You increase gqscount but the incresage will be wrong because it waits until peekmessage increases too, the timing will be wrong.

This only happens a maximum of 20/100,000 times it wont addmuch weight to the result


My new results (commenting instead of 0ing) are much different.... When commented my results are....


0.048902        34      0
0.031764        0       0
0.057923        11      0
0.053695        0       0
0.030719        0       0
0.028572        0       0
0.034822        1       0
0.030796        0       0
0.028341        0       0
0.027664        0       0
0.040897        0       0
0.027688        0       0
0.027359        0       0
0.029990        0       0
0.035721        0       0


(10 times faster without GetQueueStatus)

[redskull]

Should this method be expelled or what? You guys deside.  :cheekygreen:

The better question is why use a non-blocking version in the first place?  Unless you are writing something like a game that must "run all the time", spinning your wheels checking for non-existant messages is a waste of the CPU.

-r

[MichaelW]

You would also have to remove peekmessage to time both of them individually. You include peekmessage when getqueuestatus runs. You increase gqscount but the incresage will be wrong because it waits until peekmessage increases too, the timing will be wrong.

What would be the point of timing GetQueueStatus separately, when it is not intended for freestanding use? I was attempting to time what I thought you were describing, and expecting different results than what I got. On my system the combination of GetQueueStatus and PeekMessage is ~8 times slower than PeekMessage alone. I use gqscount to track the number of times per timed interval that GetQueueStatus indicates one or more messages in the queue, and pmcount to track the number of times per timed interval that PeekMessage returns a message. Neither of these values have anything to do with the computation of the timed interval.

[zemtex]

What would be the point of timing GetQueueStatus separately, when it is not intended for freestanding use?

If you are timing (A+B) against (A) then there is no point to remove it. However, if you intend to use getqueuestatus to run 100,000 times when there are no messages, it is relevant because you would be stuck with no messages for 100,000 iterations.  :wink

[MichaelW]

The better question is why use a non-blocking version in the first place?  Unless you are writing something like a game that must "run all the time", spinning your wheels checking for non-existant messages is a waste of the CPU.

Yes, the difference in CPU utilization is large. If I comment out the display code to prevent it from further loading the CPU, I get essentially a 100% utilization for the non-blocking loop, and 0 to ~10% utilization (depending on the number of messages being queued) for the blocking loop.

[zemtex]

The better question is why use a non-blocking version in the first place?  Unless you are writing something like a game that must "run all the time", spinning your wheels checking for non-existant messages is a waste of the CPU.

Yes, the difference in CPU utilization is large. If I comment out the display code to prevent it from further loading the CPU, I get essentially a 100% utilization for the non-blocking loop, and 0 to ~10% utilization (depending on the number of messages being queued) for the blocking loop.

May I also suggest you dont use PM_REMOVE as when getqueuestatus runs, it doesnt remove the messages, but it does in peekmessage. When you're done, report the numbers back to me again  :U

[MichaelW]

If you are timing (A+B) against (A) then there is no point to remove it. However, if you intend to use getqueuestatus to run 100,000 times when there are no messages, it is relevant because you would be stuck with no messages for 100,000 iterations.  :wink

PeekMessage and everything below it runs only if GetQueueStatus returns non-zero, so in the absence of messages GetQueueStatus is being called a million times per timed interval, and PeekMessage is being called zero times. If I comment out the PeekMessage call and the IF block below it, there is essentially no change in the timings. Your idea of using GetQueueStatus to test for messages was good, but it turns out that GetQueueStatus is just too slow to be useful for this.

[zemtex]

If you are timing (A+B) against (A) then there is no point to remove it. However, if you intend to use getqueuestatus to run 100,000 times when there are no messages, it is relevant because you would be stuck with no messages for 100,000 iterations.  :wink

PeekMessage and everything below it runs only if GetQueueStatus returns non-zero, so in the absence of messages GetQueueStatus is being called a million times per timed interval, and PeekMessage is being called zero times. If I comment out the PeekMessage call and the IF block below it, there is essentially no change in the timings. Your idea of using GetQueueStatus to test for messages was good, but it turns out that GetQueueStatus is just too slow to be useful for this.

Replace PM_REMOVE with PM_NOREMOVE and report the numbers back to me again  :U

Change 2 I want you to do as well: Run the peekmessage in a while loop until the message buffer is emptied.

[MichaelW]

Replace PM_REMOVE with PM_NOREMOVE and report the numbers back to me again  :U

I had already tested that and there was no change in the timings that I could see, but it's not really meaningful because then you have a non-functional message loop. For the blocking loop in my test above I used GetMessage.

[zemtex]

Replace PM_REMOVE with PM_NOREMOVE and report the numbers back to me again  :U

I had already tested that and there was no change in the timings that I could see, but it's not really meaningful because then you have a non-functional message loop. For the blocking loop in my test above I used GetMessage.

It makes all the difference. You get second delays when you replace it. GetQueueStatus is way faster here. And if you run that loop in a true program, you will miss alot of messages if the traffic is heavy because you dont use a while loop.

I hope you see the difference. GetQueueStatus does not remove the message, but peekmessage does, so only the very first iteration is qualified to time the two functions. (UNLESS you are willing to replace PM_REMOVE with PM_NOREMOVE, if you do that you will discover huge delays using peekmessage)

[MichaelW]

It makes all the difference. You get second delays when you replace it. GetQueueStatus is way faster here. And if you run that loop in a true program, you will miss alot of messages if the traffic is heavy because you dont use a while loop.

I hope you see the difference. GetQueueStatus does not remove the message, but peekmessage does, so only the very first iteration is qualified to time the two functions. (UNLESS you are willing to replace PM_REMOVE with PM_NOREMOVE, if you do that you will discover huge delays using peekmessage)

I have no idea what you mean. If there is a valid point buried in there some where, post code that demonstrates it.

[zemtex]

It makes all the difference. You get second delays when you replace it. GetQueueStatus is way faster here. And if you run that loop in a true program, you will miss alot of messages if the traffic is heavy because you dont use a while loop.

I hope you see the difference. GetQueueStatus does not remove the message, but peekmessage does, so only the very first iteration is qualified to time the two functions. (UNLESS you are willing to replace PM_REMOVE with PM_NOREMOVE, if you do that you will discover huge delays using peekmessage)

I have no idea what you mean. If there is a valid point buried in there some where, post code that demonstrates it.

What you seem not to understand is that peekmessage removes the message and runs 99.9% with an empty message queue, while getquestatus runs with a full message queue all the time when you should have emptied it when it discover a message.

Replace PM_REMOVE with PM_NOREMOVE and report the numbers back again. Copy the numbers and report them in again.  :cheekygreen:

Here is from your code: invoke PeekMessage, ADDR msg, NULL, 0, 0, PM_REMOVE
Replace the last argument with PM_NOREMOVE. (tip for you)

Here is your real numbers:
About 5 times slower than GetQueueStatus. (OFFTopic joke: Whats funny about that is that peekmessage also uses 5 times the amount of arguments  :lol)

[MichaelW]

What you seem not to understand is that peekmessage removes the message and runs 99.9% with an empty message queue, while getquestatus runs with a full message queue all the time when you should have emptied it when it discover a message.

I understand what PeekMessage does. My code removes the messages, whether it's configured to run PeekMessage alone, or run PeekMessage after GetQueueStatus indicates that there are messages in the queue. It does what you describe here:

Anyway, I always use GetQueueStatus for quick hint if there is messages available before i pass the execution to the slow (5 push) peekmessage function. GetQueueStatus only has 1 push and it checks a few flags. If the message loop runs 1 million times in 10 ms, that means peekmessage is pushing and popping 5 million times (Thats alot of memory reading) Microsoft SDK also mentions that getqueuestatus is the fastest possible way to check if there are available messages.

And the results show that GetQueueStatus slows the message loop down. There is no point in testing GetQueueStatus alone because it will not be used alone. There is no point in testing PeekMessage with PM_NOREMOVE because without some way to remove the messages, the message loop and application will not function correctly.

Here is a sampling of my results without the GetQueueStatus code:

Code Select Expand


0.140525        13      0
0.140405        14      0
0.140311        8       0
0.140667        13      0
0.139825        7       0
0.140351        9       0
0.139806        0       0
0.140035        0       0
0.139867        0       0
0.140347        0       0

And a sampling with the GetQueueStatus code:

Code Select Expand


1.142921        9       9
1.140578        0       0
1.140418        6       6
1.138636        15      15
1.143593        3       3
1.144531        0       0
1.137575        0       0
1.143059        0       0
1.140317        0       0
1.142379        0       0


I'm done here.

[zemtex]

What you seem not to understand is that peekmessage removes the message and runs 99.9% with an empty message queue, while getquestatus runs with a full message queue all the time when you should have emptied it when it discover a message.

I understand what PeekMessage does. My code removes the messages, whether it's configured to run PeekMessage alone, or run PeekMessage after GetQueueStatus indicates that there are messages in the queue. It does what you describe here:

You forgot the while loop my man, you forgot the while loop.  :bdg

And the results show that GetQueueStatus slows the message loop down. There is no point in testing GetQueueStatus alone because it will not be used alone. There is no point in testing PeekMessage with PM_NOREMOVE because without some way to remove the messages, the message loop and application will not function correctly.

There is nothing that forces you to use peekmessage, keep in mind the different filters available to getqueuestatus. And its twin-cousin getinputstatus can be used effectively in combinations as well.

The point of using PM_NOREMOVE is to test the individual functions up against each other. Peekmessage have an "exit strategy" in your 1 million time iteration loop. GetQueueStatus has no "exit strategy". Once peekmessage discovers a message it removes it instantly while GetQueueStatus is not able to do that while in a real program GetQueueStatus would not be stuck in such a position to not be able to do that and PeekMessage would never run once with an empty buffer.

GetQueueStatus is much faster in checking a message buffer than what peekmessage is. And this proves my point and microsoft as well that GetQueueStatus is faster, but you have to be careful where you use it. Bad implementation is your own responsibility.

One usage could be to run GetQueueStatus once per second and then run PeekMessage in a while loop.
Another usage could be to look for paint messages, which would be too time consuming to do in peekmessage.

Whatever the usage is, as long as it gives positive progress in the program, it should be used.
I'm out of here myself.