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