worley@EDDIE.MIT.EDU (Dale Worley) (01/05/90)
The choice of a gap buffer implementation is based on the assumptions that: (1) looking at a file is much more common than changing it, (2) changes tend to be tightly clustered, and (3) you have enough available physical storage to keep any buffer you are actively altering in memory. Generally, these assumptions are true. The resulting advantages are that the accessing code is small and fast (particularly for searches over large buffers) and understandable. Yes, if you expunge a thousand small messages from an RMAIL file, it is very slow. However, it is just about the worst case for a gap buffer, and its pattern of accesses is very abnormal. If you want to see how to improve Emacs' speed, first meter it and discover whether gap movement accounts for much of its run time, in real usage. And if so, try to optimize those three lines of code before declaring the gap buffer dead. As far as 24-bit integers/pointers goes, back even a few years ago, 1 megabyte was *huge* and no one expected that 16 megs would be a practical limit. Unfortunately, hardware technology evolves faster than software, and Gnu Emacs will soon have to recode the tag and address extraction macros. Dale Worley Compass, Inc. worley@compass.com -- In the shopping malls, in the high school halls -- conform or be cast out! In the basement bars, in the backs of cars -- be cool or be cast out! -- Rush, "Subdivisions"