If statements vs case

[Richard Gaskin]

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.

>> local sResult
>> 
>> on mouseUp
>>  -- number of test iterations:
>>  put 10000 into n
>>  -- load var with all possible values:
>>  put "abcde" into s
>>  --
>>  --
>>  -- TEST 1: if-then
>>  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
> 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. :)

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com