If statements vs case

Hershel Fisch hershf at rgllc.us
Mon Feb 26 15:15:05 EST 2007


On 2/26/07 1:37 PM, "Richard Gaskin" <ambassador at fourthworld.com> wrote:

> Hershel wrote:
>> Is the below the original code, if yes I'd make some comments if possible.
> 
> The switch example is the same, but the if-then example was rewritten in
> an attempt to better match the logic of the switch block.

I'm sorry this is the equivalent to the below case " but its still slower
not 20%  but a bit.
 
 put 0 into sResult
  put the millisecs into t
  repeat n
    --
    repeat for each char tVar in s
      If tVar ="a" or tVar ="b" then
        DoThing1
      else 
        --if tVar = "c" or tVar = "d" then
        if tVar = "c" then
          DoThing2
          DoThing3
        else
          if tVar ="d" then
            DoThing3
          Else
            If tVar ="e" then
              DoThing4
            End if
          end if
        end if
      end if
    end repeat
    --
  end repeat
  put the millisecs - t into t1
  put sResult into tResult1

>> this one is out of the order how about with out this line because its not in
>> sequences and the same thing below its not comparable to the case statement.
> 
> If we omit that line then DoThing3 is always triggered for C, D, and E
> as well, and because the if conditions are exclusive E wouldn't move on
> to trigger DoThing4.
> 
> The fall-through feature of switch blocks means that in the example
> below only C will trigger DoThing2, but both C and D will trigger
> DoThing3, while E skips those and triggers only DoThing4.  If the value
> of tVar is C, it will first execute DoThing2 and then move on to also
> call DoThing3, but for D it'll skip C's part and call DoThing3 only.
> 
> There may be a more effecient way to represent that with if-then than
> what I came up with, but logically I believe it should be equivalent.
> 
> 
>>>        if tVar = "c" then
>>>          DoThing2
>>>        end if
>>>        DoThing3
>>>      Else If tVar ="e" then
>>>        DoThing4
>>>      End if
>>>    end repeat
>>>    --
>>>  end repeat
>>>  put the millisecs - t into t1
>>>  put sResult into tResult1
>>>  --
>>>  -- TEST 2: switch
>>>  put 0 into sResult
>>>  put the millisecs into t
>>>  repeat n
>>>    --
>>>    repeat for each char tVar in s
>>>      switch tVar
>>>      case "a"
>>>      case "b"
>>>        DoThing1
>>>        break
>>>      case "c"
>>>        DoThing2
>>>      case "d"
>>>        DoThing3
>>>        break
>>>      case "e"
>>>        DoThing4
>>>      end switch
>>>    end repeat
>>>    --
>>>  end repeat
>>>  put the millisecs - t into t2
>>>  put sResult into tResult2
>>>  --
>>>  -- show results:
>>>  put "if:"&t1 &"ms"&&"switch:"& t2&"ms"&cr&\
>>> "if result:"& tResult1 &&"switch result:"&tResult2
>>> end mouseUp
>>> 
>>> 
>>> on DoThing1
>>>  add 1 to sResult
>>> end DoThing1
>>> 
>>> on DoThing2
>>>  add 2 to sResult
>>> end DoThing2
>>> 
>>> on Dothing3
>>>  add 3 to sResult
>>> end Dothing3
>>> 
>>> on DoThing4
>>>  add 4 to sResult
>>> end DoThing4
> 
> 
> Mark Smith wrote:
>> Richard, I bow to your more extensive test. All I did was a simple
>> five-way switch/if (based on a random input)  that actually did
>> nothing, so I think your test is probably more useful.
> 
> I wouldn't be so sure. :)  It wouldn't be the first time I've flubbed a
> test.  As Eric Chatonet says, merde happens.
> 
> In fact, in terms of real-world performance neither random values nor a
> fixed list will reveal true real-world results, since the frequency of
> accessing the different parts of each example will depend on the
> specifics of the context it's used it.  In some respects, a traditional
> Chinese scientist might concur with your use of random here. :)




More information about the use-livecode mailing list