Visual Designers and SELECT CASE AS LONG

[Theo Gottwald]

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:

Code: [Select]

    SELECT CASE CID&
 

Why not:

Code: [Select]

    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 at the end.

The SELECT CASE AS LONG is one of the strong sides of Powerbasic in terms of speed.
Why is it not more often used?

[Petr Schreiber]

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

[Chris Boss]

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.

[Dominic Mitchell]

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?

[Chris Boss]

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 !

[Patrice Terrier]

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.

[Dominic Mitchell]

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.

[Edwin Knoppert]

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.

[Eros Olmi]

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

[Patrice Terrier]

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). 

...

[Theo Gottwald]

How 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:

Code: [Select]

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?

Code: [Select]

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.

[Charles Pegge]

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.

[Theo Gottwald]

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

And here:

Behind PB - SELECT CASE

[Eros Olmi]

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.

[Theo Gottwald]

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.