Re: How to current close window while messages still in queue
On Wed, 05 Nov 2008 23:58:04 -0500, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
Reading any variable is faster than a kernel call, which is why, if you have the polling
in an inner loop, the kernel call really, really, really hurts your performance. For
example, polling every pixel, even of a simple bool, is a Bad Idea; polling at the end of
each row of pixels is better; polling every 10 rows is still better, etc.; the trick is to
balance the "shutdown latency" against the cost of the poll. But a kernel call is VERY
expensive (and a wait of 0 does lose the quantum, which is REALLY expensive), so should be
done only infrequently (single-digit-integer-per-second is not unreasonable)
I concur, but I would expect the quantum to be given back unless there is
some pathological effect like the "ping-ponging" I mentioned in my reply to
David, or some other CPU-intensive process running concurrently. I had to
rebuild my computer recently, and I have only an XP VC6 VM available, but I
can easily do well over 1E6 WFSO(0)/sec. Not blazing fast, but consider
everything else the OP was doing in his loop. It does slow down (say) if I
drag a window around while the program is running (30% or so), so there is
definitely something to the time slice issue. When I copy the program out
of the VM to my PC, it's roughly twice as fast, and as expected, it doesn't
slow down when I try to mess it up since my PC is dual core. In conclusion,
I'm not sure what the right optimization is here (not enough context), but
testing with WFSO before each and every PostMessage is likely overkill as
you say.
Whenever someone mentions the expense of kernel calls, I always think of a
Unix program famous for calling an unbuffered kernel read for every
character. Does that ring any bells? I can't think of the name of it, but
ISTR the author was rather excoriated for having done it.
--
Doug Harrison
Visual C++ MVP