4

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?

Improve this question
5
  • 1
    Do you have an implementation that clearly shows there is no advantage in doing things the way emacs now does?
    – Emacs User
    Sep 7, 2015 at 20:53
  • The Elisp manual sections about buffers might help with this question (dunno) - node Buffer Gap, for instance. If you don't get a helpful answer here, you might ask the mailing list [email protected].
    – Drew
    Sep 7, 2015 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 7, 2015 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 7, 2015 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 8, 2015 at 5:04

1 Answer 1

Reset to default
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:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.