GNU Emacs, memory usage, releasing

[Piercarlo Grandi]

I have done some tinings on my 4 MIPS 386 clone, with System V.3.2,
and using crash(1M) to get the times (down to centiseconds) for the
tests I have made.

The first table is about editing /etc/termcap, which is about 80KBytes
long, the times are cumulative in seconds.centiseconds, and they have
a quite wide margin of variability, but are "typical":

OPERATION	Emacs 18.54	MicroGNU 2a	Jove 4.12

		user	sys	user	sys	user	sys

1)  startup	0.45	1.10	0.02	0.10	0.12	0.67
2)  C-X C-F	0.51	1.96	0.71	0.44	0.66	1.18
3)  C-X C-Q	0.54	2.08	0.74	0.47	0.66	1.20
4)  SP		0.62	2.26	0.74	0.48	0.66	1.20
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
8)  M-<		0.75	3.24	0.82	0.56	0.69	1.36
9)  SP		0.82	3.53	0.82	0.75	0.69	1.36

Comments:

1) Is just to invoke an empty editor. GNU Emacs pays dearly for its
size and complication here.

2) Reads 80KB in. GNU is relativley quick, it just copies the file
to memory. MicroGnu reads it into memory and threads it into a list
of lines, and Jove copies it to a temporary file and threads into a list
the offsets of lines in this file.

3) This is only to remove the RO property from the buffer.

4) Insert a space at the beginning of buffer. GNU has to move the gap, which
is initially at the end of memory, and pays a lot here. The other two take
less than a centisecond, GNU seven. This is 70 milliseconds for moving 80KB,
or somewhat more than a MB per second on a 4 MIPS machine. Note the
relatively high system time for Emacs. Thi is due mostly to redisplay.

5) Go to the end of buffer. This involves no gap movement, just redisplay.
System times show it. On my 386 the frame buffer (an Hercules clone) is
abjectly slow, and the device driver for it correspondinglu clocks up system
time.

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.

8) Go back to the beginning of buffer.

9) insert another space there.

I have some other times for GNU Emacs before and after putting in memcpy(3)
instead of looping. Well, moving the gap is about three times faster.

	Note that on cached machines this can be further improved; the
	hardware string move instructions typically hard coded in memcpy(3)
	and friends are often very suboptimal. On a cached machine you
	really want to split your transfer in three parts (if long enough!),
	a head and a tail that are copied byte-by-byte, and a body that is
	copied one cache line at a time, and is cache line aligned in the
	*destination*.  Especially on machines with write thru caches,
	writing cache line aligned cache line sized chunks is *vastly*
	faster, as it avoids the cache fetching a line only to partially
	update it and hold ups at the memory interface. I remember that on
	a VAX-11/780 with an 8 byte SBI write buffer, writing aligned 8 byte
	transfers was *tremendously* effective.

The lesson I derive from these timings is that creating the linked list of
lines, and especially copying the file to a temporary as well, slow down
file reading time, but then further operations become very much faster. Note
also that both MicrGnu and Jove are somewhat carelessly coded, with lots
of quadratic algorithms.

Ah, another note: in my favourite editor buffer organization, I would use
the gap method, for *intra* line editing, as it avoids a lot of these
quadratic situations (e.g. repeated inserts or deletes).
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk