Xref: utzoo comp.editors:1256 gnu.emacs:2117 comp.unix.wizards:20075 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!isc-br!jimc From: jimc@isc-br.ISC-BR.COM (Jim Cathey) Newsgroups: comp.editors,gnu.emacs,comp.unix.wizards Subject: Re: GNU Emacs, memory usage, releasing Keywords: GNU emacs malloc memory working set gap editor Message-ID: <2691@isc-br.ISC-BR.COM> Date: 9 Jan 90 19:20:13 GMT References: <1558@aber-cs.UUCP> <1025@uc.msc.umn.edu> <1060@uc.msc.umn.edu> Followup-To: comp.editors Organization: ISC Systems Corporation, Spokane WA Lines: 59 >The better solution, made relatively easy by the reasonably modular and >layered structure of GNU emacs, would be to accept The Emacs Cookbook >recommendation (adopted by Jove and the MicroEmacs/Gnu family of editors) and >implement a linked list system. I would suggest just reading (or map, on the >operating systems that allow it) the file to be edited as a large lump of >virtual address space, then building a linked list of pointers to lines >therein, and then to allocate modified lines from ageneral purpose arena. >Informing the OS of the peculiar access patterns would also help, if >possible. So long as line-oriented operation preserved the ability of Gnu Emacs to edit binary files that have no 'lines' at all. The MicroEmacs we have here will choke on these (as does vi, ed, see, siv, and all the other editors we have), and MicroEmacs' line orientation is so badly implemented that if (at our site) the file is larger than about 50K it is _faster_ to start emacs on the file than MicroEmacs. MicroEmacs starts faster, but it reads files _much_ slower (fgets,malloc,strcpy). Somebody or other's master's thesis was on buffer styles (I got a copy with my copy of MINCE a few years ago), and his conclusion was that the gap method worked best. That may have been on a machine that wasn't DPV, though. Moving the gap by, say, 20 characters should affect at most two pages (four, if you assume it straddles a page boundary on both ends but this is true for any scheme and may be disregarded). A block with a line pointer array might also affect two pages (the block and the buffer array) so I don't offhand see the advantage. Jumping about wildly would touch a lot of pages, but the assumption is that you work a lot in one place. The gap approach makes it very quick to _save_ files, so the auto-save feature is unobtrusive. It would be absolutely useless if it took 5-10 seconds to rearrange the line-pointer and block mess to get it into savable form, or write a line at a time. If realloc can't do the right thing it should be replaced by one that can. I believe GNU isn't interested in supporting non-GNU machines (read VAX) to the extent that it corrupts the architecture of the program. I somewhat agree with them in that broken environments shouldn't be catered to, but repaired instead. It would be nice if emacs did sbrk- when it could. In our environment, we can also release holes in the _middle_ of the heap. We added an additional system call for it. This gets pages out of the swap space, but they'll be reallocated (and cleared to zero) if you touch in the hole. We have a limited virtual address space (2M on some machines, 4M on most others) so GNU can't edit those really big log files. I think only elle can of the editors I've experienced. I think it uses linked blocks. GNU Emacs _is_ awfully large, though, but I haven't noticed any machine eating behavior. Of course, we have a lot of smaller machines here, so few use it at once. Far more noticible is simultaneous compiles. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"