🚀 go-pugleaf

In article <2927@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:
>In article <11293@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr) writes:
>
>   my experience so far has been that the more general a component is, the
>   slower it runs.  for example, given a routine to sort objects, you have
>   to give it a criteria.  somehow, the sorting routine has to make a
>   function call to compare two elements.
>
>Not necessarily true.  Given a good enough development system, the
>compiler can inline the function call (even to the point of it
>becoming a single machine instruction!).  This leads to a slower
>compile, so for test runs it's easier to leave the function call in
>(at the expense of speed).

	You're both right.

	Inlining can help for very small functions, or larger ones at the
cost of a lot of program size (and even speed, in a paging or cached
hardware environment).

	The original poster is right though: as the hardware becomes faster,
and the programs we write become more complex, we are moving to higher
levels of abstraction to keep the complexity from overwhelming us (or making
it too expensive to do).

	Take a program like omega.  Massive unix game written in C, >1Meg
of source.  It would run much faster and be smaller if written (well) in
assembler.  However, it would never have come close to being completed.
We trade off efficiency of execution/size for cost of production (programming).
The same thing occurs in the ever-higher level toolboxes we use in costruct-
ing programs, like XWindows, databases, "software ICs" (still not really
well-understood or very useful yet, though they may well be eventually),
and things like nExt's Interface builder.

	This has happened from the very beginning of the computer industry,
and there have been no indications this will stop in the forseeable future.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup