|
From: | Alin Soare |
Subject: | Re: line buffer as Red Black Trees instead of linear |
Date: | Fri, 16 May 2014 11:53:25 +0300 |
The values that need to be precomputed are the metrics of each
"display element" (character glyph, stretch glyph, image glyph, etc.)
that will (or would) be displayed when/if the line is shown on the
screen. Your suggestion calls for precomputing those in advance,
while the current implementation computes them only when they are
actually needed. I very much doubt that your suggestion, if
implemented, will be a net win.
It might make sense to cache the values, once they are computed, so
that any subsequent routines that need to access the same portions of
buffer text won't need to recompute the same metrics. But before this
kind of caching is attempted, Someone(TM) should demonstrate that the
same portions of the long lines are traversed by the display engine
more than once, because otherwise what you suggest will be pure
overhead with no hope of any gains.
"Premature optimization is the root of all evil." (Donald Knuth)
> The solution of this problem is the red-black trees, by inserting at each
> node all the pre-computed characteristics of the block of text kept at the
> given node. Any modification will pre-compute a finite number of nodes, and
> when need to access them , only a logarithmic # of nodes will be taken in
> consideration for all possible operations.
I would suggest to study the relevant code and, more importantly, time
it to find the _real_ (as opposed to imaginary) hot spots. Then
present that data, and we could thereafter discuss whether your
suggested solution might indeed speed up the code which takes up the
lion's share of the time when Emacs needs to display very long lines.
If indeed these techniques could help, patches will be very welcome,
as this is an annoying problem, and there's a bug report for it (see
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13675).
[Prev in Thread] | Current Thread | [Next in Thread] |