Optimization for speed or size

spolsky@eniac.seas.upenn.edu (Joel Spolsky)
Fri, 5 Aug 88 12:20:59 edt

          From comp.compilers

Related articles
Optimization for speed or size spolsky@eniac.seas.upenn.edu (1988-08-05)
| List of all articles for this month |

Date: Fri, 5 Aug 88 12:20:59 edt
From: spolsky@eniac.seas.upenn.edu (Joel Spolsky)
Posted-Date: Fri, 5 Aug 88 12:20:59 edt

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

Post a followup to this message

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