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

Visual Designers and SELECT CASE AS LONG

<< < (9/9)

Steve Hutchesson:
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.

Edwin Knoppert:
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).

Navigation

[0] Message Index

[*] Previous page

Go to full version