lingo12,
That depends on how much code a particular message handler has to execute. If it is a lot, it is conceivable that the search code and table are moved out of the L1 cache. If it is a very large amount, then it is possible to get moved out of the L2 cache. My Athlon is supposed to have 64kb for data and 64kb for instructions in the L1 cache, and 128 kb for the L2 cache. Ratch
Posted on 2003-01-16 21:05:06 by Ratch
Ratch,

I know that and prefer to see part of your code, but anyway...
What do you think about Hutch's "High speed message dispatcher" in Algo section?
Is it an alternative?

Regards,
Lingo
Posted on 2003-01-16 21:59:07 by lingo12
As it happens I implemented a dispatcher using a jump table... shouldn't be too hard, though, to get it up as a binary jump table. I'm wondering how a jump table compares to the three methods...? BitRAKE's results seem to show that it doesn't even come close to the others.
Posted on 2003-01-16 22:17:16 by AmkG
lingo12,
I have not looked at the Hutch's high speed dispatcher yet. Stay tuned. As requested by you, my code is included in this message. Ratch
Posted on 2003-01-16 23:39:02 by Ratch
lingo12,
I looked at Hutch's "high speed dispatcher". It should be the fastest of all, if the message numbers are within the 4k range, and memory is not a consideration. The big 64k L1 data cache of the Athlon should go a long way to help speed things up even more, if the message processing does not kick the address table out of L1. But unless you have lotsa different messages to process, or need to do it fast, it is like using a 747 to taxi to the local grocery store. Ratch
Posted on 2003-01-18 00:33:29 by Ratch
To the ineffable All,
I don't suppose I am telling anyone something they don't already know. I just ran a frequency of hits study on different message numbers that the dispatcher handles. I used a fairly small typical program. The WM_CREATE, WM_CLOSE, WM_DESTROY, and WM_SIZE messages were called one or two times. The second highest was WM_COMMAND at about 15 times. However, the many messages sent to default precessing were received more than 2300 times. Therefore, the quicker a dispatcher can acertain a message is destined for default processing, the quicker it can get rid of it. Most of the methods discussed above dispatch messages to default processing at the very end of all the other message determinations. Even though they are BY FAR the most often received messages. If something like a range test could be done at the beginning to quickly cull out all or most of the messages for default processing, that should greatly speed up the process. Ratch
Posted on 2003-01-19 13:22:09 by Ratch
and of course you're going to notice the speed difference of any optimizations in a windows message dispatcher. oh yes.
Posted on 2003-03-30 14:53:36 by f0dder
From testing the speed difference from the slowest to the fastest, in a WndProc where the messages are being produced from the guts of Windows, I doubt that anything else than a very large app would benefit from the technique I have suggested but if you are branching on the basis of characters or sequential numbers or similar where the branching is to a very large number of locations, a pre calculated table of addresses will outperform and sequential evaluation method by a long way.

Regards,

hutch@movsd.com
Posted on 2003-03-31 04:58:25 by hutch--