IT-Berater: Theo Gottwald (IT-Consultant) > SDK and Third Party Know-How

Visual Designers and SELECT CASE AS LONG

(1/9) > >>

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 CASE CID&
 
--- End code ---


Why not:


--- Code: ---    SELECT CASE AS LONG CID&
--- End code ---

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 !

Navigation

[0] Message Index

[#] Next page

Go to full version