compilation speed with enough memory

Leroy Dorman mp1 at sdcc12.ucsd.EDU
Tue Jul 19 15:26:09 AEST 1988


In article <Jul.13.11.23.02.1988.1755 at athos.rutgers.edu>, hedrick at athos.rutgers.edu (Charles Hedrick) writes:
> 
> I made a comment in a previous posting that compilation and loading on
> SV/AT seem incredibly slow.  I now believe that much of that was due
> to insufficient memory.  At the time I wrote my posting, I had 1.6M of
> memory (640K plus 1M).  I just added another 512K, to make 640K+1.5M.
> This seems to have gotten rid of most of the extraneous swapping
> during compilation and loading.  (As far as I can tell, by the way,
> this swapping is not caused by insufficient memory, but is done to
> shuffle memory in order to satisfy sbrk requests.  One would think it
> would be possible to avoid this, but having not looked at the kernel,
> it's hard to be sure.  

Kernel schedules a swap from sbrk if innsufficient core
is available BEFORE releasing the core that the process has. So
you need 2 * (current proc size) + requested additional bytes of
core to avoid swapping. Lots of memory here is helpful.

Don't know why uPort hasn't added in a scheme to simulate a
releae of the proc's current memory space and THEN reallocate
memory. Took me all of 1 day to make it work. Improved compiles
on my Intel 286/310 machine (Multibus At&t Release V/286)
(8Mhz 286, 1Mb memory) by 35%!!

ld is particularly slow when searching libraries and building
symbol tables because of the many mallocs/sbrks that get done.

------------------------------------------------------
Eric Dorman				Kirk- "Wheels, Mr. Spock"
University of California, San Diego	Spock- "A flivver, Captain"
Scripps Institution of Oceanography	  From- A Piece of the Action"
 siolmd!eric at sdsioa.ucsd.edu



More information about the Comp.unix.microport mailing list