nick@nswitgould.OZ (Nick Andrew) (03/25/88)
I'm very puzzled by the behavior of the Minix Fix program. When run
with a stack+malloc size of 3000 bytes, Fix runs extremely slowly. When run
with an additional 3000 bytes to play around with, Fix runs TEN times as
fast. [ Background: Minix 1.2, using 1.2 lib & 1.1 compiler ]
These are the figures:
Old file length 17184 characters (actually the V7 compatible Ar)
Diff file length 2055 chars
Output (stdout) 17640 chars
Fix with chmem =3000
Real 1:03.0
User 7.2
Sys 53.4 (wow!)
Fix with chmem =6000
Real 7.0
User 2.5
Sys 2.4
That's quite a large improvement. I thought maybe the
#define copy(s) printf("%s",s)
statement was slight overkill so I changed it to an fputs(). That made
an improvement in the execution times of both of the above, respectively
Fix with chmem =3000 and fputs
Real 59.0
User 6.8
Sys 51.1 (not much of an improvement)
Fix with chmem =6000 and fputs
Real 4.0 (40% improvement)
User 2.0
Sys 0.3 (85% improvement)
It seems that either streams, or standard output buffering is having
this marked effect on the speed of the system. Fix does not call malloc etc.
Can somebody with a good knowledge of the internals shed some light on this?
... I know a certain amount of buffering helps performance, but this
is incredible ...
Nick.egisin@watmath.waterloo.edu (Eric Gisin) (03/29/88)
In article <7616@nswitgould.OZ>, nick@nswitgould.OZ (Nick Andrew) writes: > > I'm very puzzled by the behavior of the Minix Fix program. When run > with a stack+malloc size of 3000 bytes, Fix runs extremely slowly. When run > with an additional 3000 bytes to play around with, Fix runs TEN times as > fast. [ Background: Minix 1.2, using 1.2 lib & 1.1 compiler ] > This was a common problem with large programs on V7 too. The program fopen's a file. Fopen cannot malloc a buffer because it cannot expand the data segment. So fopen leaves the file unbuffered, and everything gets read/written one byte at a time. That's why you see the high system time.