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