Xref: utzoo comp.editors:1230 comp.unix.wizards:20002
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.editors,comp.unix.wizards
Subject: Re: GNU Emacs, memory usage, releasing
Keywords: GNU emacs malloc memory working set gap editor
Message-ID: <1564@aber-cs.UUCP>
Date: 4 Jan 90 18:05:11 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 28

In article <692@augean.OZ>  writes:
    In article <1561@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
    }5)  M->		0.65	2.45	0.78	0.53	0.67	1.26
    }6)  SP		0.71	2.58	0.78	0.53	0.67	1.26
    }7)  SP		0.71	2.70	0.78	0.53	0.67	1.26
    }
    }6) Insert as space as the last chracter. This moves the gap again, and
    }it shows. Also redisplay.
    }
    }7) Add a second space at the end. Just redisplay really, and minimal as to
    }that.
    
    Your data does not justify your conclusion. If the .71 sec for GNU
    emacs in 6 is (mainly) due to the movement of the gap, then why is the
    time identical for 7 when, as you say, no gap movement occurs?

They are *cumulative times*; this means that adding the second character
costs less than a centisecond in usert time, while the cost in system time
is almost all redisplay.

However your point that redisplay is *expensive* is very true. How much of
this is due to GNU emacs, and how much to the incredible slowness of my
machine's frame buffer, I don't know. One should really profile  (both
these points I have already made in my posting... :->).
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk