Optimization for speed or size
Joel Spolsky
> Some compilers have options to select what kind of optimization to
>do: space or time. ... For example, in the fragment:
>
> X = Y
> X = Z
>
>it's obvious that removing the code generated from the first statement will
>do both. To my naive mind, it seems that the difference between the two
>types of optimization would be rather small.
Not many programmers write code like that. One way to speed up a
program by making it larger would be to code subroutines inline and
avoid the overhead involved in making the call; a good way to shorten
a program but make it slower would be to create subroutines for every
imaginable duplication of code:
(Optimize for size) (optimize for speed)
begin begin
call subproc; a<-b;
whatever; c<-d;
call subproc; e<-f;
end; whatever;
subproc: a<-b; a<-b;
c<-d; c<-d;
e<-f; e<-f;
return; end;
Clearly, it depends how often your subroutines are called, how long
they are, how significant the overhead for calling is, etc. For
example, in a routine to draw a bit-mapped image that called a subroutine
to draw each pixel, you could probably speed things up a great deal by
coding in the pixel-draw routine directly, although this is sure to
result in repeated code and a longer program. Whereas if you had to
squeeze your program into a minimum amount of space you could
certainly find segments of repeated code that could be made into
subroutines thus shortening your program.
Joel Spolsky
Bell Communications Research
spo...@eniac.seas.upenn.edu
--
Send compilers articles to ima!compilers or, in a pinch, to Lev...@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-request