Nikolai Weibull wrote:
> On 8/16/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> > There are only a few operations that profit from a "gap" strategy.
> > Overall it gets much more complicated and inefficient. You would have
> > to move the gap around for every change made.
>
> Not quite true. You'd have to move it around for every
> /length-altering/ change made (but non-length-altering changes work
> well without a gap as well).
Just about any change will potentially change the length. Keep in mind
that changing a character may change the byte count for multi-byte
characters.
> And considering that insertion is the most common operation and that
> it's one of the operations that would benefit, it's a trade-off that
> may or may not benefit buffer modification as a whole.
Insertion is just one of the many operations. And it's one that can be
put in a function used from many places, while other changes are much
more specific and require separate implementation.
> Still, I suppose the most common scenario for the most common
> operation is insertion at the end of a line, which I assume there /is/
> support for in Vim already, i.e., allocating some additional space for
> every loaded line so that one doesn't have to realloc() for every
> insertion.
Not really. I don't think it makes sense to optimize for one of the
very many operations. Keeping the code simple and reliable is much more
important.
> Remember: Emacs uses the gap strategy for the whole buffer, and I
> haven't seen this to be particularly inefficient. The big problem is
> the continuity of the buffer in memory, which isn't much of a problem
> on a per-line basis.
I have never seen a reliable, real-world comparison of performance for
various strategies. Only ones with so many assumptions that the result
becomes meaningless. You quickly get to the situation that the outcome
mainly depends on the type of edits you test with. The mechanism Vim
uses is probably too complex for scientific research anyway.
Optimizing for file loading is one thing that could still be done in Vim
and would probably improve performance. Currently every line has to be
copied after it has been read. I know it's possible to avoid that, but
quite a bit of work (esp. for testing, this code has to be very
reliable). Since I don't hear remarks that loading a file is slow it's
not high on the priority list.
--
hundred-and-one symptoms of being an internet addict:
161. You get up before the sun rises to check your e-mail, and you
find yourself in the very same chair long after the sun has set.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
