Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!cbmvax!vu-vlsi!swatsun!schwartz
From: schwartz@swatsun (Scott Schwartz)
Newsgroups: comp.lang.c
Subject: Re: goto's in C: an opinion...
Message-ID: <1234@thebes.swatsun.UUCP>
Date: Tue, 28-Jul-87 17:25:59 EDT
Article-I.D.: thebes.1234
Posted: Tue Jul 28 17:25:59 1987
Date-Received: Fri, 31-Jul-87 01:46:16 EDT
References: <3289@bigburd.PRC.Unisys.COM> <28700017@ccvaxa>
Organization: Swarthmore College, Swarthmore PA
Lines: 38
Summary: how much faster with goto's?

In article <28700017@ccvaxa>, aglew@ccvaxa.UUCP writes:
+-------
| 	When you've completed an application nicely in C,
| 	using functions everywhere, and it's still too slow,
| 	which would you rather do?:
| 
| 	(1) Rewrite parts of it in assembler,
|      	or (2) Use gotos?
+-------

I would profile it and rewrite parts in assembler.  

We've all heard that line before, so no one should be surprised that it
turns out to be the case.  I can't think of any sizable program that would
exibit a _dramatic_ speed increase when you ripped out switches and 
if-then-else's to put in goto's.  The only case where this seems to be
any kind of issue is in state machines and parsers;  there has been enough
discussion both ways on this recently to convince me that goto's are not
necessarily the best way to do it in every case.  

I happen to like the "ErrorExit" usage that was talked about in several
prevous postings, but I disagree with the insinuation above that functions
are too slow to be practical.  Two experiences come to mind:  The first
case was an egrep style program I once wrote, the second was a ray tracing
program a friend of mine wrote.  In both cases I wanted to speed things up
without doing rewrites in assembler.  So I tried replacing some of the
functions in the inner loops with inline expansions [naturally a good
optimizing compiler would have done that for me, but...].  The functions I 
chose to replace were identified (using unix profiling tools) and were
called over 300,000 times in the test run.  Replacing with inline code
made virtually no difference in execution time.  What I concluded from
this exercise was that quick fixes usually don't work, and that in many cases
function calls are less expensive than you think, especially if you 
have a naive compiler.

-- 
# Scott Schwartz 
# ...{{seismo,ihnp4}!bpa,cbmvax!vu-vlsi,sun!liberty}!swatsun!schwartz