Optimization for speed or size

roy@phri.uucp (Roy Smith) Writes:


> 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
spolsky@eniac.seas.upenn.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.