In section 11.18 of the GNU Emacs Manual, it's mentioned that buffers with a large number of lines line-number-display-limit or with particularly long lines line-number-display-limit-width might experience slow performance with line number calculation and so line number calculation is disabled by default. It seems to me that using a tree-like structure you could get logarithmic-time insertion and random access if every subtree kept track of the number of elements in it. What advantage is there in doing things the way emacs does?
Asked
Active
Viewed 390 times
4
Greg Nisbet
- 857
- 5
- 19
-
1Do you have an implementation that clearly shows there is no advantage in doing things the way emacs now does? – Emacs User Sep 07 '15 at 20:53
-
The Elisp manual sections about buffers might help with this question (dunno) - node [Buffer Gap](http://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Gap.html), for instance. If you don't get a helpful answer here, you might ask the mailing list `emacs-devel@gnu.org`. – Drew Sep 07 '15 at 20:58
-
@EmacsUser Yi uses finger trees for its buffers. I don't know enough about emacs to experiment with ripping out the buffer data structure and replacing it with something else. – Greg Nisbet Sep 07 '15 at 21:00
-
This is a fun question. One consideration is that a tree probably needs more memory allocation and certainly has worse locality of reference, than a "dumb" data structure like an array keeping a gap at point? – Greg Hendershott Sep 07 '15 at 22:10
-
I made the title conform better to the content of the question, but I am not thrilled with it. My question is sort of open-ended and I am not sure what a good summary would be. Have people looked into replacing the buffer implementation? – Greg Nisbet Sep 08 '15 at 05:04
1 Answers
3
Personally, I doubt the buffer implementation can be blamed for every performance problem people encounter with buffers. My specific problem with it did involve long lines that were slowing down redisplay, a known issue with a multitude of reasons behind it, including Bidi rendering, excessive movement of point crossing the problematic line and less than ideal font-lock. I did plan on implementing a cache for line operations just to find out that such a cache does already exist. After upgrading to Emacs 24.5, the issue was gone for me in Python REPL buffers, simply because font-lock was only applied for the input line and no more in the output.
tl;dr: There is no silver bullet. Don't believe this is just a technical problem. Do your own research, profile if you know how (perf should be ideal, gdb could work as well) and share your insights.
References:
