There is one thing, i wonder about.
All the Visual Designers I have tested (Three until now) until now, spit out Message Loop-Code like this:
SELECT CASE CID&
Why not:
SELECT CASE AS LONG CID&
This is something that really makes me wonder, because these two words "AS LONG" are free - they will not cost a thing.
And the difference in the ASM code is that its highly optimized (http://www.jose.it-berater.org/smfforum/index.php?topic=1140.0) at the end.
The SELECT CASE AS LONG (http://www.jose.it-berater.org/smfforum/index.php?topic=1140.0) is one of the strong sides of Powerbasic in terms of speed.
Why is it not more often used?
Hi Theo,
I think the reason could be to maintain backwards compatibility for possible PBDLL/6 users?
The "AS LONG" was introduced in v7.
I must agree it is very advantageous to use SELECT CASE AS LONG whenever it is possible.
It means extra speed without any special effort. I can usually see 5-6x better performance when using it, even with low number of CASEs.
Bye,
Petr
For backwards compatibility.
EZGUI 4.0 Pro can be used with the Pb 5.x, 6.x, 7.x, 8.x compilers, as well as with recent console compilers.
I didn't want to have to force users to have the lastest compiler.
That said, my DDT Designer though will require PB 8.x or later, so that is a good idea.
How is optimizing the message loop and message filter in a WndProc going to speed up an app?
This is the part that interacts with the user. Am I missing something?
Most messages (or events) don't occur in rapid fire, so using SELECT CASE LONG won't speed up things when used in the message cracker code.
Now of course if you process messages like mouse movement (WM_MOUSEMOVE) or the cursor select message (WM_SETCURSOR) which do occur in rapid fire, then the message cracker code may be improved in speed by using SELECT CASE LONG.
The speed at which a normal SELECT CASE executes though is quite fast enough so you won't notice any slowdown.
When you have CPU's running at 2 ghz or better, a PB app can execute thousands (maybe millions) of floating point comparisions per second.
For example, EZGUI apps have a SELECT CASE with strings (for testing for form names) which is much, much slower than comparing for floating point values. Even though string comparison is much, much slower, it executes so fast that most apps will see no sideffects (slowdown) from it.
Why optimize code, when it offers no obvious effect to the end users experience !
It all depends of the type of code you are writing.
For example in a real time application like BassBox, everything must be processed at the fastest speed, especialy the WM_TIMER message, then the use of select case long as well as other optimizations is highly recommended.
Sorry, but SELECT CASE AS LONG is not goint to make a dent in any of the examples quoted.
This is a misconception that is also prevalent on the PB forums.
Input from the user is a slow process. It does not matter how fast the user types or moves
the mouse, the program still has alot of idle time between each message. Updating the screen,
however, is a painfully slow process for a program.
To the user, objects on the screen appear to move faster when their movement is smooth rather
than jerky. Therefore, for smooth animation the timer trick works very well because the program
is not tying up the system with many BitBlt's in a short period of time with small changes in position
shape or color that, by the way, are not discernible to the human eye. That is the reason why
WM_PAINT is a low priority message.
WM_TIMER is the message with a priority even lower than that of WM_PAINT. The timers that cause
this message to be generated by the system have a resolution of about 10 to 52 milliseconds.
That is a long time that will significantly cut the number of BitBlt's done by animation code.
In a *rare* occasion i need speed in code what the enduser will use.
I don't recall any important SELECT CASE statement used in such functions.
Most of my com functions are late bound, guess what that could have an impact if i needed speed.
Most of the things in my designer just can be slow.
I use a lot SELECT CASE AS LONG in thinBasic engine.
Using it with or without AS LONG makes a lot of difference due to the use I make of it, mainly are loops with big SELECT CASE AS LONG ... executed many thousands of times per seconds.
But if SELECT CASEs a not much (let's say less that 10 CASEs) IF/ELSEIF clause is much faster than SELECT CASE AS LONG
Another benefit of using SELECT CASE LONG is its small exe size reduction. :)
SELECT CASE has a lot of work to do, to branch onto the good case, especialy when they are not in order.
And one of the worst case, is using a STRING to select the good CASE (even using SELECT CASE STRING).
...
QuoteHow is optimizing the message loop and message filter in a WndProc going to speed up an app?
I know that Dominic is right - we are talking from the message loop which normally has only to do with user interaction.
And this is most often not timecritical.
Therefore it can be understand that he and Chris rather keep compatibility and don't look at some extra bytes.
I did not think of this when posting the mesage. I just wondered.
Besides that I think everybody should always have the latest PB-Compiler :-).
Taking compatibility aside, the two extra words will not cost a thing and produce more efficient results at the end.
Thats why I said "Use it - its free!".
Also there are few exceptions, for example when we have to do with Mousemove-Messages.
These may occur very often and then it is a difference which sort of SELECT CASE is been used.
Anyway, the words from Dominic and Chris stands, as most programmers will not analyze Mousemoves,
and therefore its more a principial question I made here.
My personal idea why SELECT CASE AS LONG is not often used, was that it is not available in C, and many programmers
have a strong C background. Ifyour native language is SPAIN, you'll think in SPAIN, translate and write it down in ENGLISH.
Thinking in native PB bigger then V.7 we should prefer AS LONG wherever it can be used (not only in SELECT CASE :-)).
Let me threw in another issue about the Message-Loop.
We have heared this before, when we discussed if the
ISFALSE() should be used at the same place.
As said, my recommendation to replace the
ISFALSE, is this a simple
MACRO:
MACRO FUNCTION zero(P1) = ((P1)=0)
Usage:
IF zero(A&) THEN ? "ISFALSE(A&) would be true here."
The ISFALSE is a general command which is made to work also under general (Quads,FPs, logic) conditions.
When we only want to
test for zero in a LONG or BYTE, we should do exactly that:
Test for Zero.
Internally this can be done with a few ASM Commands and PB will compile them if we tell it to do so.
The same thing, why use slower (because more general usable) commands, when you can user faster (because more specific) commands
at no price?
to select the good CASE (even using SELECT CASE STRING). Yes, Patrice. Depending on the case, it may be an idea to think of using either:
-> SELECT CASE AS CONST$
or think of another construct. While peopel will say that in many cases these speed things do not really matter.
Ayway in automatically generated code, I think it should not only be very readable, but also optimized when the readability is not worse.
That's interesting Eros, that IF ENDIFs can be faster than SELECT CASE AS LONG
I favour IF..END IF over SELECT CASEs because it makes program logic easier to alter. In low level code they should look the same, but the ultimate SELECT is a jump table like ON..GOTO which should be fastest of all. This however is best suited to a contiguous set of CASE values.
In information technology these are quite different pairs of shoes, the simple-two-way choice or the multiple choice.
Each one has its usage to be the programmers tool for the similar real-life situation. Using the right construct keeps your code readable and usable.
And btw. the speed advantage of the IF THEN before the SELECT CASE depends on the usage and may be even a disadvantage, you can find details about this here:
Behind PB - IF THEN (http://www.jose.it-berater.org/smfforum/index.php?topic=1174.0)
And here:
Behind PB - SELECT CASE (http://www.jose.it-berater.org/smfforum/index.php?topic=1140.0)
I personally prefer SELECT CASE AS LONG ...
It give me better code to maintain (in terms of reading) when later I need to add new cases.
But this is just a personal ... taste I suppose.
I am just asking myself "How important is SPEED to me?"
Normally Speed is not a issue.
But even in my actual project, all subprogramms are streamlined and are really fast.
After all the user has no waiting time and his system will work normal with no CPU Usage
while this tool will run in the background.
It will not be a DOTNET Tool. Thinking like this, I believe Speed is really important for me -
or lets say Efficiency (http://en.wikipedia.org/wiki/Algorithmic_efficiency).
I suppose any extreme concept is not worth unless you are in an experimenting field.
For many projects speed in not a matter. In other yes.
It depends on the project or, better, it depends on the specific task to be performed because even if in a project the whole speed is not a matter, some tasks inside are speed dependant. I think that in any case optimization must be taken into account since the beginning of the project (oops: maybe I'm too extreme here :D) .
For the projects I'm working on Speed is 50% of the whole importance. Of course stability is obviously at number 1.
I agree that it can make a program less obvious when scanning through but I favour a uniform structure which caters for all conditions, cases and loops. It makes program logic much more extensible, and apart from jump tables, should be just as efficient. If you need to add, modify or remove any of the clauses, there is far less editing to do than if other constructs are used.
I find that optimising code makes it more 'brittle' for future alterations. So this needs to be avoided till the final stages of development.
In the spirit of extreme minimalism, This is the whole uniform structure I use , no other control structures are needed ( apart from the occasional goto :) ). It is also very easy to 'assemblerise'
do
if ..
exit
end if
..
continue
loop
Minimalism ...
They tried to make RISC CPUs sometime ago. Then they dropped the concept and started over with CISC.
Because they realized that to much minimalism is not the worlds destination.
In fact, I think what they did was: They took the good things out of it.
Datastructures are technical representations of real-life decisions.
Of course you can break it more and more down, but then at the end you land on ASM level or below.
The structure of a algo should be possibly translated into written code.
For example, if you have a real-life situation to decide between 50 different choices, but you know that you will only ned one at the end,
you should be able to formulate it like this.
Using pure IF.. ELSE .. ENDIF as we know it, this may not work.
Using IF .. THEN .. ELSEIF ... ENDIF it may be an alternative, thats why PB has it.
But in some cases, when the decision is just dependent on a single amount,
the SELECT CASE AS LONG is the best choice in terms of speed and readability.
Otherwise I could we wouöld soon be back to RISC but it did not stand in history.
Therefore I believe that Minimalism just for its own reason is a failed concept.
Its only good to remove unneeded redundancy.
I found that by using this simplified structure, logic bugs were practically eliminated. In particular the absence of ELSE clauses makes it far easier to check the correctness of the code.
So the minimalism in this case pays off very well. But I agree the minimalism if inappropriately applied makes coding more difficult by having to create workarounds for absent constructs.
BTW, in terms of compactness this compares favourably with a SELECT structure. The only extra is the 'EXIT' command at the end of each case. In C, cases have to have an explicit 'break' anyway.
do
if a=.. then ..: exit
if a=.. then..: exit
' case else here
exit
loop
QuoteI found that by using this simplified structure, logic bugs were practically eliminated. In particular the absence of ELSE clauses makes it far easier to check the correctness of the code.
This sentence proofs, that you've never studied on a university.
Otherwise you should have heared the sentence (free tranlated from german)
"
A two side-choice where only one side is given, is most often a program-mistake."
This is somehow a basic statement in information technology science (excuse my not so perfect english :-).
But in practise, choices are usually more than 2 sided - in fact you can never be sure how many choices will be necessary. Hence the need to deploy an extensible logic that is easy to check.
The extensibility is achieved by adding to the list or by nesting to any level. When you start nesting inside ELSE clauses, the logic can become extremely tangled with multiple negatives. modifications to the code then become hazardous. In this instance, It is often easier to dump the whole structure and rewrite it from scratch rather than attempt to extend it.
Beware false dichotomies, especially from computer science theory (and politicians).
QuoteBeware false dichotomies, especially from computer science theory (and politicians).
hehehe
For me, I used some of these scientific ideas in my programm and i believe its good for their stability.
Anyway it doesn't mean there is no other way to write good programm.
About politicians ... this is actually not a science but near to religion. Therefore we should not directly compare it to technological questions.
While ... if we go into OOP we also get into religion somehow. :-)
I ran some tests to see which performs the best. SELECT CASE AS LONG or SELECT CASE AS CONST performs as fast as an Assembler compare list. Plain SELECT was 8 times slower. (taking empty loops into consideration)
The IF THEN result was most interesting as it appears to outperform the assembler test.
It seems that the compiler omits empty IF clauses or those which are never used. Can't tell which.
#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
DIM c AS LONG
DIM i AS LONG
DIM t AS SINGLE
t=TIMER
DO
INCR i:IF i>1e8 THEN EXIT LOOP
c=3
#IF 0
SELECT CASE AS CONST c
CASE 0
CASE 1
CASE 2
CASE 3
CASE 4
CASE 5
CASE 6
CASE 7
CASE 8
CASE 9
END SELECT
#ENDIF
#IF 0
ON c GOTO 0,1,2,3,4,5,6,7,8,9
GOTO nx
0: GOTO nx
1: GOTO nx
2: GOTO nx
3: GOTO nx
4: GOTO nx
5: GOTO nx
6: GOTO nx
7: GOTO nx
8: GOTO nx
9: GOTO nx
nx:
#ENDIF
#IF 0
! mov c,3
a0:
! cmp c,0
! jnz a1
! jmp nx
a1:
! cmp c,1
! jnz a2
! jmp nx
a2:
! cmp c,2
! jnz a3
! jmp nx
a3:
! cmp c,3
! jnz a4
! jmp nx
a4:
! cmp c,4
! jnz a5
! jmp nx
a5:
! cmp c,5
! jnz a6
! jmp nx
a6:
! cmp c,6
! jnz a7
! jmp nx
a7:
! cmp c,7
! jnz a8
! jmp nx
a8:
! cmp c,8
! jnz a9
! jmp nx
a9:
! cmp c,9
! jnz nx
! jmp nx
nx:
#ENDIF
'#if 0
IF c=0 THEN GOTO nx
IF c=1 THEN GOTO nx
IF c=2 THEN GOTO nx
IF c=3 THEN GOTO nx
IF c=4 THEN GOTO nx
IF c=5 THEN GOTO nx
IF c=6 THEN GOTO nx
IF c=7 THEN GOTO nx
IF c=8 THEN GOTO nx
IF c=9 THEN GOTO nx
nx:
'#endif
LOOP
MSGBOX STR$(TIMER-t)
' results in seconds:
' SELECT CASE c: 4.4
' assembler cmp... 1.03
' SELECT CASE AS LONG c 1.06
' SELECT CASE AS CONST c 0.905
' ON C GOTO 01 02 ... 0.87
' IF THEN .. 0.609
' (empty loop) 0.505
'
END FUNCTION
Charles,
SELECT CASE AS CONST is valid only if you compare against a sequence of low numbers like 1,2,3,4,5 ...
If compare values are high value, PB will generate big comparison tables and execution time will increase a lot.
Eros
Ah yes, PB uses a jump table for SELECT AS CONST. You can see the EXE file jump in size as it creates a table to cover the highest number. But the speed remains the same no matter what the number of cases might be. For this test with 20 cases:
SELECT CASE AS c 10 secs
SELECT CASE AS LONG c 3 secs
SELECT CASE AS CONST 1 sec.
PS: it seems to be 6 bytes*max case number for the table.
#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
DIM c AS LONG
DIM d AS LONG
DIM i AS LONG
DIM t AS SINGLE
t=TIMER
d=RND
DO
INCR i:IF i>1e8 THEN EXIT LOOP
c=3
SELECT CASE AS CONST c
CASE 090
CASE 190
CASE 290
CASE 390
CASE 409
CASE 590
CASE 690
CASE 790
CASE 890
CASE 990
CASE 000
CASE 100
CASE 200
CASE 300
CASE 400
CASE 500
CASE 600
CASE 700
CASE 800
CASE 900
END SELECT
LOOP
MSGBOX STR$(TIMER-t)
' results in seconds:
' SELECT CASE c: 10
' SELECT CASE AS LONG c 3
' SELECT CASE AS CONST c 1
' (empty loop) 0.505
'
END FUNCTION
Quote from: Eros Olmi on March 03, 2008, 01:19:29 PM
SELECT CASE AS CONST is valid only if you compare against a sequence of low numbers like 1,2,3,4,5 ...
If compare values are high value, PB will generate big comparison tables...
Eros
I'm surprised you'd say that, Eros, as it is simply not true.
It might be a good idea to head over to the PowerBASIC web site and learn how it works so you won't have to speculate as fact. Just GOTO www.powerbasic.com -- Choose "Help Desk" -- Then choose the complete documentation for either PB/CC or PB/WIN and follow the link to SELECT CASE. You'll find a complete description there of the methodology of SELECT CASE CONST. You might be surprised!
Or, you could write a small sample program and try it.
Best regards,
Bob Zale
PowerBASIC Inc.
Quote from: Charles Pegge on March 03, 2008, 01:56:09 PM
PS: it seems to be 6 bytes*max case number for the table.
Actually it's 4 bytes per CASE, plus a very small fixed overhead.
Best regards,
Bob Zale
PowerBASIC Inc.
Hey Mr Zale, welcome here!
I think I've completely read PB help file at least twice. I know what's there better than what you can expect.
From PB803 help in case of "SELECT CASE AS CONST":
QuoteWhile this form of the structure offers the utmost performance possible, the execution speed must be carefully weighed against the increased program size, particularly when using sparse case values. For example, with just two CASE values of 2 and 1000, the generated jump table would need 999 table entries (3996 bytes in size).
Did I say something different?
Yes, maybe my sentence would have been: "Pay attention that if your possible CASEs are too sparse, there can be some performace issues."
ADDED:
here we are on a free not censored forum and we are allowed to make some little "semantic" error.
Why don't you jump also into the many posts where others and I make big compliments to PB products? Maybe just to say: thanks guy.
You said:
"SELECT CASE AS CONST is valid only if you compare against a sequence of low numbers like 1,2,3,4,5 ... If compare values are high value, PB will generate big comparison tables..."
The PowerBASIC DOC says:
"Performance is enhanced by the internal creation of a vector jump table, one entry for each number from the smallest to the largest case value."
That's very different and very misleading to those not closely familiar with the product. Not exactly a small "semantic" error.
Best regards,
Bob Zale
Quote from: Eros Olmi on March 05, 2008, 04:25:36 PM
"Pay attention that if your possible CASEs are too sparse, there can be some performace issues."
Unfortunately, that too is a very misleading statement. There are no performance issues. SELECT CASE CONST in PowerBASIC executes at the identical speed regardless of the number of CASE's. A structure with 20,000 CASE's executes in the same elapsed time as one with 2 CASE's. That's precisely why we designed this feature in the way we did.
Best regards,
Bob Zale
PowerBASIC Inc.
Hello Bob,
Thanks for your comment on SELECT .. AS CONST.
I ran some further tests to check the jump table sizes, and it is definitely 6 bytes * max number. With a span limit of 3000 entries as far as I can tell. Assuming you are using indirect jumps (4 bytes) , I think that the discrepancy is due to the fixup tables that EXEs use for resolving addresses at run time.
Hi Charles...
Your statement was: "...it seems to be 6 bytes*max case number for the table..."
Fortunately, fixup entries in a portable executable (PE) file are not a part of the memory image, nor are they part of the SELECT CASE jump table, as you stated. The table is four (4) bytes per CASE number from smallest to largest, not per max case number.
That makes an astounding difference in many situations.
Best regards,
Bob Zale
PowerBASIC Inc.
Yes Bob, I was just looking at the file size rather than considering the memory image.
One interesting result we found is that for small numbers of cases, (say 10) SELECT AS LONG has a very similar timing to SELECT AS CONST. This is probably due to the CPU's branch prediction abilities.
They do some amazing tricks these days and one cannot be certain how long a sequence of ops will take.
An Idea:
For very large constant spans, it is possible to set up a virtual jump table. This example shows how this can be done. With a span of 100,000, which would not be tolerated by the compiler, and would, in any case add 600k to the size of the file, this code will achieve similar performance to SELCT CASE AS CONST .
' Creating a virtual jump table for extreme constants
#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
LOCAL i,j,vtable,which AS LONG
DIM t(1e5) AS LONG
vtable=VARPTR(t(0))
j=CODEPTR(xit) ' default location
FOR i=0 TO 1e5:t(i)=j:NEXT
t(01024)=CODEPTR(aa) ' case constant
t(42935)=CODEPTR(bb) ' case constant
t(99900)=CODEPTR(cc) ' case constant
'...
' select case as const
which=42935 'example
! mov eax,which
! shl eax,2
! add eax,vtable
! jmp dword ptr [eax]
aa: 'case
MSGBOX "AA": GOTO xit
bb: 'case
MSGBOX "BB": GOTO xit
cc:
MSGBOX "CC": GOTO xit
xit: ' end select
END FUNCTION
@Charles, you are right, and that exactly is what PB does with SELECT CASE as CONST.
Let me add that in the case of an comparisson of "IF THEN ELSE" and SELECT CASE AS LONG" speed differences are so small that they can be even different on other manufacturer CPU.
Therefore I assume both as equal. While for good reasosn, the "normal" SELECT CASE is slower, because for more general use.
We see this often, that a tool that is less specific for a case, (= more general) is a bit slower.
I already posted on this case, here:
SELECT CASE Comparison (http://www.jose.it-berater.org/smfforum/index.php?topic=1167.0)
But - at least PB 8.03 seems to had an limitation of a
maximum of 3057 choices for SELECT CASE AS CONST before getting the Error 402.
Now you wrote:
QuoteA structure with 20,000 CASE's executes in the same elapsed time as one with 2 CASE's
Was there a
table-increase in PB 8.04 or do you talk from something we all do not know if it exists,
but hope it will be available soon (PB 9)?
Let me state that I have never needed 3000 cases, but just wondered that you give this number 20000.
I personally do not need such an big jump table, and therefore I do not wait for this, really - but
I can imagine bussiness programms who would like to get that much big.
There is
one limit I do not really understand and this Limit is not 3000 but
6. Its the "include/Macro nesting Limit".
People making small programms and utilities upto 200, 300 kb may not even know that this exists.
But then on bigger projects, this limit may show its teeth.
When I load an Include file, this one loads an include file, that loads an includefile and that file calls a MACRO that calls a MACRO that calls a MACRO.
This limit is not 8, its not 32 or 256 its 6. I do not understand
how it comes just to this number 6.
But anyway, I can say, that I hope, that this limit will fall one day in the future, as this would make some things a bit easier.
Even if it would be - for example just 38 (38 = 32 + 6 :-) I'd be Ok.
Theo, I also get the same limitation of ~3000 CASE number span on PB version 8.04. The virtual table solution is a way out of this, and minimises the file size. Perhaps a future release of PB could adopt this approach, who knows :)
Well the combination of inline assembler and Basic makes just about any programming technique possible. The language is virtually future-proof but you don't get the symbolic notation to go with new ideas or paradigms.
Well, if you's ask me, this is one of the fields I would be most happy of improvements.
At least PB has a very reliable inline assembler already and the possibility to make inline Macros.
But of course there is more thinkable.
I think the original question as less to do about speed than it does about understanding what the code does. You ask, "Why not use SELECT CASE AS LONG rather than just SELECT CASE if it produces faster code?" And someone else will reply: "It does? I didn;t know that. I guess I will use SELECT CASE AS LONG from now own, because I want my code to be faster".
Here is another question: Is it better to use FUNCTION PBMAIN, FUNCTION PBMAIN(), FUNCTION PBMAIN AS LONG, FUNCTION MAIN, or one of the declaratives for FUNCTION WINMAIN for your main body of code? Some people, mostly those with PB/CC, would just use FUNCTION PBMAIN, whereas those with PB/Win probably prefer FUNCTION WINMAIN which requires that you sepecify the parameters. Why? Does it really make a difference most times? Do you gain anything if you include the AS LONG? Probably not, so why do some people do it?
I think it comes down to this: In the SELECT CASE situation, you are aware of the benefit of including AS LONG because you explored the subject, and this is your way of showing people that this might be a good thing to do. Fine. But the argument that followed about whether it really makes a difference in the perception of performance is equally valid, because it is very difficult to quantify such things. In the final analysis, all that really counts is whether the written code does what it is suppose to do, and is the performance level adequate. If not, the solutions is often to just get a faster PC, not to go back and tweak existing code in an effort to milk a bit more performance speed out of it.
Quote from: Theo Gottwald on March 05, 2008, 09:25:41 PM
Bob, if you read this, maybe you can clarify one thing for me, that noone else can.
In my tests, it showed - exctly as you said - that SELECT CASE AS CONST is good, for a large number of choices, as it does not need to go through all those needless comparison but jumps directly where it should.
Hello Theo, Charles, et al
We love to hear of your continued interest in PowerBASIC. But I am sure you understand that PowerBASIC representatives cannot possibly monitor 10 to 20 boards to provide PowerBASIC technical support. We must centralize our support in one location: www.powerbasic.com visit soon or bring these questions and we will be very happy to discuss it with you.
Its interesting to read a topic of this age as it has some useful information init that still applies to the later compiler versions. With the original question, if you are using integers there is no reason not to use the Select Case as LONG notation apart from the slight increase in typing.
he CONST option in select case is in fact very useful when writing high level code. In MASM if you want a jump table, you place an aligned table with the labels as the table members then make indirect jumps based off the table start address + indexed label locations in the table but for design reasons PowerBASIC excludes module level scope for labels so that technique is possible but very messy to set up to work.
One of my toys, the tiny MASM editor called TheGun uses a jump table in the WndProc and it yielded a drop in assembled size and the technique tests up very fast but even with the rate that messages are being fed through the WndProc, the data throughput is far slower than the technique will handle so while its cute, it does not justify the effort to buid it.
Now where the Select case as CONST came into its own was with a scripting engine that I wrote a few years ago where you are parsing lines of script on a criterion of leading command or alternatively the word after return value and "=" symbol. I did a direct jump back to the start label after each branch to the case location to reduce the overhead and after gutting the complete instruction fetching loop it was testing up last time I played with it at a bit over 3 million instruction fetches a second. Drop the CONST and the fetch performance drops very badly so in this case the technique fully justifies the minor size increase from using the jump table code in Select Case.
Unfortunately the type of design was vulnerable to the virus idiot fringe sneaking malicious scripts into it that would write binary to disk and run it so I stopped development of the engine as a stand alone app and later used it as the scripting engine in my current MASM editor as a DLL. This blocked malicious scripts from being able to be run without the user knowing it as a script must be started in the editor. With the fetch loop running in more or less constant time for all commands and functions, scripts written and run by the script engine run at about the same speed as a normal binary file.
Since i write me a visual designer i feel somewhat spoken to, the TS mentions SELECT CASE AS LONG in respect to a messagepump.
Imo it's pretty nonsense to take this particular part of a program to speed up, you'll gain nothing, and i mean nothing towards the enduser.
There is program code and there is interface code.
Interface code will always be a slower part of a program, this is normal Windows behaviour.
There is so much overhead windows got to do anyway that using a SELECT CASE AS LONG won't help you at all.
Also, how is it possible one decides to use a large number of jump parts in a messagepump?
I have a select case in SDK mode yes, but it handles only 2 jumps, i never use the MP for alternative catching, i never had a need to.
The messagepump will only work when no program code is executed and the computer is somewhat idle (or given time).