Re: Compiling ooc-951220

[acken@informatik.uni-kl.de]

>  From: Frank Copeland <fjc@wossname.apana.org.au>
>  
>  It wasn't an exact measurment, but I typically have around 3.7M free and
>  compiling this module just about exhausted free memory. I don't have
>  virtual memory like you do on Linux, so its quite a serious concern. The
>  last time I tried to install VMM (a virtual memory manager) I got nothing
>  but crashes, but there is a new version out so I might try again.
>  
My figures weren't that correct either.  To compile ParseStatm I need
4.2M, to run a `make all' on the whole sources I need 5.7M.  

>  On top of that my allocator adds an overhead of 8-12 bytes for record
>  allocations and 12-16 bytes for dynamically allocated open arrays. The
>  exact amount depends on rounding by the OS. Allocating lots of small
>  structures is *bad* news. I keep meaning to implement a more efficient
>  allocator, and this may be the right incentive :-).
>  
The GSA data structure needs a very high degree of flexibility, and
the overall setup has to be simple in order to keep the algorithms
operating on it simple.  So lots of heap objects are needed,
especially the number of allocated Operand objects is very high.  o2c
adds an overhead of 8 bytes to every record, and 0 bytes to arrays.
But this works only because I don't have to worry about gc.

>  Most of these situations are reasonably uncommon. I think if it was made
>  optional, with perhaps warnings generated when the compiler detected
>  one of these conditions, it would be the best of both worlds.
>  
I agree.  The benefits are small, and are usually not needed when
doing a simple edit-compile-debug cycle.  On the other hand, it may
improve code quality for the library modules and modules importing
them.  In my opinion the `standard' setting of the compiler should
make compilation fast, with most of the optimizing enabled.  A
additional `optimize til you drop' setting would do all the things
necessary to produce the `best' code.  This setting would include
keeping all procedures in memory, inter module procedure inling,
iterative optimization runs, etc.

>  Frank

-- Michael