Related articles |
---|
Optimization tradeoffs (time vs. space) roy@phri.uucp (1988-08-01) |
Re: Optimization tradeoffs (time vs. space) markhall@pyramid.pyramid.com (1988-08-05) |
Re: Optimization tradeoffs (time vs. space) ames!coherent!dplatt@ncar.UCAR.EDU (1988-08-05) |
Re: Optimization tradeoffs (time vs. space) tekcrl.tek.com!willc@RELAY.CS.NET (Will Clinger) (1988-08-06) |
Re: Optimization tradeoffs (time vs. space) gbs@nsc.nsc.com (1988-08-08) |
Optimization tradeoffs (time vs. space) midkiff@uicsrd.csrd.uiuc.edu (1988-08-09) |
Re: Optimization tradeoffs (time vs. space) roy@phri.uucp (1988-08-10) |
Re: Optimization tradeoffs (time vs. space) mmengel@cuuxb.ATT.COM (1988-08-11) |
From: | Will Clinger <tekcrl.tek.com!willc@RELAY.CS.NET> |
Newsgroups: | comp.compilers |
Summary: | inlining and loop unrolling save time, cost space |
Date: | 6 Aug 88 01:57:59 GMT |
References: | <1853@ima.ISC.COM> |
Organization: | Tektronix, Inc., Beaverton, OR. |
I agree that most optimizations that save time in C-like languages also
save space, and vice versa. Someone mentioned the C switch statement
as an exception; loop unrolling and procedure integration are others.
In some languages the time/space tradeoff is more dramatic. For example,
generic arithmetic operations such as addition in Scheme and Common Lisp
are too complicated to code in line. The compiler has two practical
alternatives. One is to use a subroutine call. The other is to generate
code for the most common (fixnum) case in line together with code that
traps to a subroutine for all other cases. The simple subroutine call
is more compact but is slower. Arithmetic is so ubiquitous that this
can make a significant difference.
moderately typical # of instructions for generic (+ x 1)
static dynamic
subroutine call 2 7
inline with trap 6 4
William Clinger
Semantic Microsystems, Inc.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.