Memory used for IF/THEN vs. SELECT CASE

[Mike Luther]

For a long integer related run of IF THEN and ELSEIF THEN vs. a
long run of SELECT CASE type codement, which takes less memory and
is more efficient in PB 3.5 for DOS?


Thanks!


------------------
Mike Luther
[email protected]

[Michael Mattias]

Speed:
If I recall correctly (and I may well not...)
SELECT CASE (numeric) under PB/DOS always uses single-precision comparisons, regardless of 'original' datatype.. whereas IF..ELSEIF..ELSE..ENDIF uses whatever datatypes are specified (assuming you have used matching datatypes in your code)... which suggests that IF..ELSE..ELSEIF will be faster unless you are comparing SINGLE variables, in which case it's a wash.
But you can easily write a program to test this.

Memory:
This has got to be a wash, since (forced/required data conversions excepted) both IF and SELECT CASE must be compiled to a compare + jump.
But you can test this too by reading the code segment sizes and datasegment info displayed at the end of each compilation.

General:
In either case (SELECT CASE or IF) you will probably get better performance overall by making sure the 'most likely hits' are tested first than by playing with IF..ELSE vs. SELECT CASE

[Jim Martin]

Howdy -

Just to muddy the waters a little, you might consider maintenance.
Especially if you are working with several variables, SELECT CASE
allows for much easier understanding, since on a given line you
know exactly which variable is being considered and where it fits
in your program structure, particularly if you indent consistently.

If you use the IF THEN...ELSEIF...END IF structure, it's easy to
wind up with a jumbled collection of tests, and a year later start
tearing your hair out. You know, the sort of situation which gave
BASIC a bad name long ago.

Presumably, since you are worried about memory usage you are dealing
with big programs - but those are exactly the ones where you need
to keep your program structure easy to understand.

JMHO, of course. And a certain amount of painful experience. Oh, yes,
a _lot_ of painful experience.

------------------

[Mike Doty]

ON GOTO, ON GOSUB are extremely fast.
They eliminate the need to pass parameters.

------------------

[Mike Luther]

Thanks to all of you for your thoughts.

Michael .. I converted the fairly substantial three IF/THEN and ELSEIF
style romps to SELECT CASE. In this instance all of them were involved
with short integer comparisons anyway. Net change in memory of the
executable; insignificant. More interesting, if I compile the executable
as a PBD test, either way of coding this produces exactly the same size
of memory needed to run! I really have no practical way to decide which
fashion of this executes faster. You also have to be correct in the
suggestion that one should test for the most used selection items first
if possible. In this case, I can't really make use of that suggestion,
but you sure are correct there.

Jim .. You are correct also. In this case, the entire routines are only
related to a specific massive choice between integer values of a single
variable. To be specific, the actual cursor column where a mouse click
in PB 3.5 returns the variable 'column%' The task at hand here is related
to my calendar screen selection operations where the mouse click on any
point in a given area automatically selects the minute block for a user
to set that time of any two week spread of days to the start of what will
be a professional appointment in the appointment book. But in trying to
optimize the code here, I was trying to learn something. And what you
suggested as to a reason for using SELECT CASE is already in use elsewhere.

However, as a result of your suggestion Jim, I've made a decision to take
a closer look at the whole issue here for exactly the reason you gave.


Mike Doty .. You know, I've not used these techniques. I guess part of
the reason is to try my best to avoid GOTO and that for a sort of other
reason here. I'm trying my best to keep my source as uniform as possible
over the now 1,300,000 lines and 114 major chunks of PBU/PBL and main line
executables using them. However, on note of your comment, I'll see what
I can make of this ..


There is another reason for this too. Like it or not for platform final use,
I'm trying my best to style the PB source code so it can be auto-translated
to C/C++ using the Watcom C/C++ compiler. Or maybe, whatever forbid, to
Java? Gloom. So avoidace of the jump rope technique is focal to me but
I may be hurting myself there. I admit it.

---->>>> overview?

I'd like to think I'm one of the strongest advocates of PB's toolset. But
in the end, as has been proven over and over, the use of Windows is simply
out of the question. Period. Believe me, I deeply respect Bob's not
offering up promised dates for this and that. He did, IIRC, move the
operations from California to Florida, I think. But the phrase that you
hear, "We shall sell no wine before its time!", is worth a heck of a lot
to the compiler game as well. So .. for 'other platforms' it's kinda
like the Army. Good things come to those who stand and wait patiently.

In humor here, OK? A dying man pulled on the Sister's frock sleeve and
asked for a Priest, a Rabbi, and a Minister! Puzzled, she asked, "Why?"
He answered, "I'm hedging my bets .. ". We often are so curiously bound
to what the final answer in the code for life is ..

I did once meet a girl with a pet hedge hog. Interesting handling it...






------------------
Mike Luther
[email protected]

[Matthias Kuhn]

Mike,

I´ve about 10 years made programs with pb3.5.

If the program size between the "CASE"-statment is to big and
needs to much memory. I´ve see unusual errors - difficult to fix.

So I knew for bigger programs it is much better to use If..then..else.

my to pence

Regards

Matthias Kuhn

------------------