rthurlow@van-bc.UUCP (Rob Thurlow) (01/03/89)
Well, I have a few more observations about MicroEmacs 3.9-and-a-quarter. I just tried to load a large file (the Stevie editor sources from comp.os.minix, all in one file), and I had some real problems. I tried first to load the file into MicroEmacs 3.9 1/4 launched from the Gulam with my 391K ramdisk and could not. "Well fine", I thought, "I'm pushing it a bit here. :-)" So I decided to turf the ramdisk and get some numbers. First, booting my 1 Meg ST normally with no ramdisk and my normal desk accessories and AUTO programs left me with 870046 bytes free according to SCHIZO. MicroEmacs 3.9 1/4 reported that after it had loaded with no files that it had 736574 bytes available. But it was unable to load my 361409 byte file; it was only able to load 232785 bytes into the buffer before complaining that it had run out of memory. That's not very good in my books; where did the memory go? It may have been spent lavishly, but it seems more likely that the memory was just fragmented by that time. By contrast, running the Gulam shell from the same 870046 byte baseline resulted in free space from within the editor of 775942 bytes. Gulam loaded the file easily, with 215730 left over for other buffers. And with the 391K ramdisk, Gulam failed, but could fit in just a bit more of the file than MicroEmacs 3.9 1/4 could! The difference in overhead is very interesting to me; having 361K taking up 543K of memory is a whole lot better than having 233K taking up 737K of memory! Anybody have any comments about what is going on here? And can MicroEmacs 3.9 1/4 be fixed? I don't regularly edit files that big, but I do like to edit as many 50-90K USENET news batches as I can stuff in, and for that, it looks like I have to use Gulam. Of course, that's not such a bad way of doing things, either. -- ---------------------------------------------------------------- "There was something fishy about the butler. I think he was a | Pisces, probably working for scale." - Nick Danger | Robert Thurlow uunet-----\ | Vancouver, BC, Canada !van-bc!rthurlow | In the heart of Kitsilano ubc-cs----/ | ----------------------------------------------------------------
nwd@j.cc.purdue.edu (Daniel Lawrence) (01/03/89)
In article <2089@van-bc.UUCP> rthurlow@van-bc.UUCP (Rob Thurlow) writes: >Well, I have a few more observations about MicroEmacs 3.9-and-a-quarter. <he goes on to describe some memory fragmentation and usage problems....> MicroEMACS was allocating line structures only in 16 byte increments. This was very good for editing, not so good on storage. By allocating only the needed # of bytes when the file is first read in, and then allocating in 16 byte chunks when you first add a char to a line, I seem to get the best of both worlds... an apox 30% decrease in RAM usage. Look for this in the upcomming 3.10 release. Daniel Lawrence (317) 742-5153 nwd@j.cc.purdue.edu The Programmer's Room Fido 1:201/10 (317) 742-5533