I agree. Inside a real-time interaction repsonce loop (redrawing a graphic according to mouse loc) is where nested ifs alow minimal interpretor expence. Also, nested ifs demand a great understanding of the problem topology which may or may not be worth the effort. Switch statements dont allow easy stacking of decision criteria. A nested if structure allows hierarchical triage of conditional logic. A better word for "switch" could have been "first match" as it presents an ordered list of conditional tests at the same level, once a match is found the interpretor exits the switch list. For performance reasons, the ordering OS switch conditionals should correlate to the natural frequency distribution of your problem domain (most comon conditions at the top).
-----Original Message----- From: "Phil Davis" <[email protected]> To: "How to use Revolution" <[email protected]> Sent: 4/23/2009 8:29 AM Subject: Re: Switch or If Hi Camm, Unless you're building something where the small difference in speed is absolutely critical, I would seek to answer a different question: Which structure will be easier to understand and maintain in the future when I (or others) come back to it? My 2 cents' worth - Phil Davis Mark Smith wrote: > > On 23 Apr 2009, at 11:02, <[email protected]> <[email protected]> wrote: > >> All , >> >> Which is faster in a loop ? >> >> SWITCH or IF >> >> > > This is a little test I did. I get about 35ms for 'switch', about 20ms > for 'if'. As Jim said though, I suspect it'll vary according to the > kind and complexity of conditions you're testing. > > > on mouseUp > put the millisecs into tStart > repeat 10000 > put random(5) into tSw > switchTest tSw > end repeat > put the millisecs - tStart into t1 > > put the millisecs into tStart > repeat 10000 > put random(5) into tIf > ifTest tIf > end repeat > put the millisecs - tStart into t2 > > put t1 && t2 > end mouseUp > > ----- > > on switchTest pSw > switch pSw > case 1 > > break > case 2 > > break > case 3 > > break > case 4 > > break > default > > break [truncated by sender] _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
