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?
1 Answer
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:
[email protected]
.