OpenEuphoria

Re: Conceptual problem solved by GOTO

• Posted by Chris Bensler <eu at creativepo?tal?ca> Jun 06, 2008
• 736 views

ken mortenson wrote:
> 
> I keep seeing people make the same false claims about GOTO over and over.
> 
> The issue regarding GOTO vs. structured code IS NOT SPEED.  Yes, calling a
> routine to refactor code makes the refactored code slower... but you NEVER
> have to call a sub routine.  The tradeoff without using functions is SIZE
> not SPEED.  
> 
> I've identified some lines of .. some code here .. with (A) and (B)
> 
> Fernando Bauer wrote:
> > procedure proc1()
> > if cond1 then
> >    .. some code here ..
> >    if cond2 then
> >       .. some code here ..
> >       if cond3 then
> >          .. some code here ..
> >          goto OUT
> >       end if
> >       .. some code here .. (A)
> >    end if
> >    .. some code here .. (B)
> > end if
> > OUT:
> > .. some code here ..
> > end procedure
> 
> You will note in the following that line (B) is now inline in two places
> (more SIZE) but only executes once (same SPEED)  It should be exactly the
> same speed for the if to branch to the else rather than the end if.
> 
> procedure proc1()
> if cond1 then
>    .. some code here ..
>    if cond2 then
>       .. some code here ..
>       if cond3 then
>          .. some code here ..
>       else
>          .. some code here .. (A)
>          .. some code here .. (B)
>       end if
>    else
>       .. some code here .. (B)
>    end if
> end if
> .. some code here ..
> end procedure
> 
> > Now, without GOTO, we are forced to (mis)use a loop construct (for-loop,
> > while-loop)
> > where there is NO loop.
> > Conceptually, IMHO this makes no sense.
> > To avoid the conceptual problem we could use flags, but IMHO this is even
> > worst.
> 
> You are not forced to misuse a loop.  No flags either.
> 
> If your basing your desire on GOTOs because of speed you are using a false
> premise and should rethink it.
> 
> Do I prefer this refactoring?  No.  That's why I use subroutines.  But if
> I need speed I just have to make the tradeoff with code size.

That is true in alot of cases but not always. More code can sometimes cause
additional cache misses (I just learned what caches misses actually are the other
day, thx Kat :) which actually make the optimization less efficient than the
original.

This can be seen in certain circumstances simply by rearranging a few lines of
more-or-less unrelated statements. The outcome is identical, but the execution
speed changes for what seems an inexplicable reason. I have often encountered
this type of anomoly when doing benchmarks. changing the order of functions often
produces radically different results, for example.

Chris Bensler
Code is Alchemy