Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!arizona!rupley
From: rupley@arizona.UUCP
Newsgroups: comp.emacs
Subject: Re: MicroEMACS works but eats CPU on SysV
Message-ID: <3032@megaron.arizona.edu>
Date: Mon, 30-Nov-87 03:46:58 EST
Article-I.D.: megaron.3032
Posted: Mon Nov 30 03:46:58 1987
Date-Received: Wed, 2-Dec-87 03:33:36 EST
References: <422@cimcor.UUCP> <205@jc3b21.UUCP>
Organization: U of Arizona CS Dept, Tucson
Lines: 46
Summary: possible malloc problem




in article <205@jc3b21.UUCP>, larry@jc3b21.UUCP (Lawrence F. Strickland) says:
> in article <422@cimcor.UUCP>, mike@cimcor.UUCP (Michael Grenier) says:
>> In article <1107@sugar.UUCP>, karl@sugar.UUCP (Karl Lehenbauer) writes:
>>> 
>>> Anyway, emacs works just fine, but it totally eats CPU time (pretty
>>> much all that's available), even when it's just sitting there waiting for 
>> 
>> Hmmm... it does seem to be doing something strange. It grabs all the
>> CPU time on my system as well (though at a low priority) in some
>> sort of system call. What's really strange is that version 3.8i which
>
		
>
>BTW, I've run into a rather strange behaviour between uemacs on a 3b2/300
>and on a XENIX 286 machine.  Under XENIX, you can edit a 100K-500K file with
>no trouble at all.  Does take a while to read, but what doesn't?  On the
>3b2, uemacs just hangs reading the file forever (or at least more than 30
>minutes for a 100K file.  Thats all I was willing to waste).  Anyone have
>any ideas?

This is probably not a Microemacs problem.  It may be a sysV problem.  
Under Microport sysV/AT, repeated calls to malloc allocate nicely and 
quickly, up to a limit of several hundred kbytes.  Then a dramatic 
slowdown, associated with swapping.  There appears to be no easy fix.  
It may be a kernel problem.  It is not due to insufficient memory or 
swap space.  To see if something like this is happening on the 3b2, 
use:
	timex -s emacs largefilename 

and hit ^X^C to exit as soon as the file is read.  The timex output 
will allow you to identify what parts of the system are being 
exercised normally and in the slow-allocation regime.  Check for an 
increase in swapping activity, comparing the reads of small files
and large files (the latter large enough to be above the threshhold).

I would be interested in knowing if sysV on a 3b2 shows this.

John Rupley
 uucp: ..{ihnp4 | hao!noao}!arizona!rupley!local
 internet: rupley!local@megaron.arizona.edu
 telex: 9103508679(JARJAR)
 (H) 30 Calle Belleza, Tucson AZ 85716 - (602) 325-4533
 (O) Dept. Biochemistry, Univ. Arizona, Tucson AZ 85721 - (602) 621-3929