problems/risks ...

[Herman Rubin]

In article <300 at isgtec.UUCP>, robert at isgtec.UUCP (Robert A. Osborne) writes:
> lou at atanasoff.rutgers.edu (Lou Steinberg) writes:
> >jbaker at gmu90x.gmu.edu (jbaker) writes:
> >> But the real usefulness of requiring break in a switch statement is for
> >> SIMILAR treatments of similar cases, for example you may require a
> >> few assignments in one case before a more complicated computation which
> >> must be performed for several of the cases.
> >
> >ARGHHH!!  That is what subroutines (and macros) are for - to handle
> >common code.  And if your language makes them too expensive, either in
> >terms of run time or in terms of programmer effort, then THAT is an
> >even worse problem with the language than the problems with break.
> ARGHHH!! Why are we constantly bombarded with people who do not understand
> that PEFORMANCE IS SOMETIMES AN ISSUE!!!!!
> 
> I was under the impression that C's function calls are, relative to other
> high level languages, very inexpensive, (is this still true?)
> in which case if you are using fall-through to gain speed (which I have
> done several times) there is probably a good reason!

Simple, yes.  Inexpensive, no.  I can conceive of a way in which hardware
can be constructed which would make subroutine calls inexpensive, but I
know of no machine which has it.  

The following paragraph should be well known to computer users.  Unforutnately,
this does not seem to be the case.

A subroutine necessarily must find its arguments (or pointers to them, etc.)
in standardized places.  It also must put its results in such places, or use
pointers to know where to put them.  Occasionally one can put the arguments
in those places or use the results that way, but not always.  There is also
necessarily a context switch to some extent.  Even some inline procedures
have some of these drawbacks.  What used to be called open subroutines do
not have these drawbacks; in many cases, they can be replace by macros, but
not always.
.
> I'm tired of people blithly saying that "such and such is dangerous,
> and hence should be removed from the language" when I need such
> things to get interactive performance.  How many people posting to
> this group(s) are actually using C in a production environment?

This is needed for non-interactive performance also.  It is not the case
that the speed of the computer can make up for the inefficiency of the
code.  The infamous frexp function is a strong example of the inefficiencies
cause by using subroutines.  The actual code as a procedure is not much longer
than the code for a subroutine call and return, and may even be shorter.  The
speed advantage is enormous, especially if, as was done in BSD 4.2, the code
was written in C!

There is another danger from eliminating things from languages.  This has led
to eliminating them from machines on the grounds that no one needs them.  We
could probably eliminate most deaths from automobiles by limiting them to a
maximum speed of 5 mph.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)