No announcement yet.

Memory used for IF/THEN vs. SELECT CASE

  • Filter
  • Time
  • Show
Clear All
new posts

  • Memory used for IF/THEN vs. SELECT CASE

    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?


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

  • #2

    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.

    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.

    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

    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]


    • #3
      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.



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



        • #5
          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]
          Mike Luther
          [email protected]


          • #6

            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


            Matthias Kuhn