tbray@watsol.waterloo.edu (Tim Bray) (01/02/90)
In article <1558@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: To paraphrase: GNU Emacs uses a simple-minded gap-based system for managing buffer memory, and ... >Unfortunately as it is implemented in GNU emacs the "gap" method is a >disgrace for performance because: Many reasons given, quite plausible-sounding. >What are the solutions? Hold on. What makes you think you know what the problem is? Have you instrumented it with the profiler and quantified the overhead of this "problem"? My own intuition is that GNUmacs spends much more time CONSing and otherwise chugging through the innards of the Lisp interpreter. But I wouldn't bet $0.50 on my intuition unless I had a good quantitative understanding of what's going on. You propose putting in linked-list logic. Let me point out that the gap system has the *immense* advantages of being simple, comprehensible, very compact, and proven robust. You're going to be awfully disappointed when you spend weeks hacking a new buffer manager in, and the size of the code grows substantially, and it's less reliable, and then it doesn't feel any faster. Haul in soapbox, climb up: I see a lot of this particular error. After a few years in the field, we learn a lot of things about what makes programs fast or slow, and we start to suffer from the delusion that we can apply our intuition to performance issues in large systems. How to make software fast: o Use good algorithms from the top down, and o Make everything simple as possible, and o After it works, instrument it and find out where it's spending its time. Then go back and use better algorithms in the slow parts. Climbing off the soapbox and turning to another emacs issue, rlk@think.com (Robert Krawitz) says: >2) Emacs dies very quickly after its virtual size exceeds 16 Mbytes, >due to the 24 bit pointers used (the top 8 bits are used as tag bits for >the Lisp interpreter). Yes, and a lot of other problems too. Any serious programming language (Elisp is a serious programming language) with 24 bit numbers is in deep trouble. Fairly efficient solutions to this problem exist in other lisp implementations, and one will have to be hacked into Gnumacs. Finally, woods@robohack.UUCP (Greg A. Woods) writes: >Your article has convinced me that GNU Emacs is indeed, in my case, a >waste of disk space. That may be true, but nobody has presented any serious evidence to support such a conclusion. Cheers, Tim Bray, Open Text Systems, Waterloo, Ontario, Canada