[patch] improved performance when editing with a count

[Christian Brabandt]

Bram,

I recently noticed, using <nr>ifoobar<esc> can slow down vim
considerably for large numbers. This gets even more apparent when using
multibyte characters.

This happens, because getvcol() gets called several times for each
entered character and this will get worse for each entered character,
since Vim needs to loop for each entered character over the complete
line again to update the virtual column.

Here is a patch, that improves this a little bit, by making sure, that
saves a call to the getvvcol() function and does only call
update_topline and a couple of similar functions when the count is 1.

Here is a small benchmark using that patch:
time vim -u NONE -N -c ':exe "norm! <nr>afoobar\<esc>:q!\<cr>"'

<nr> Vim Patch
1000 3,6s 1,6s
2000 18,4s 6,4s
2500 29,5s 10,1s
(I didn't even try to use some really large <nr>)

As you can see, this seems to slow down exponentially. I could imagine,
that this will make Vim unresponsive even when not using <nr>a but one
only tries to append to a real long line.

I think, one could further improve that, by caching the virtual column
and not to start counting again from the beginning of a line for each
entered character. But this is more complicated.

Best
Christian
--

[Bram Moolenaar]

Thanks, I'll add it in the todo list.
In the mean time, feel free to improve it further.


--
Q: What is a patch 22?
A: A patch you need to include to make it possible to include patches.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Dominique Pellé]

Christian Brabandt <cbl...@256bit.org> wrote:

> Bram,
>
> I recently noticed, using <nr>ifoobar<esc> can slow down vim
> considerably for large numbers. This gets even more apparent when using
> multibyte characters.
>
> This happens, because getvcol() gets called several times for each
> entered character and this will get worse for each entered character,
> since Vim needs to loop for each entered character over the complete
> line again to update the virtual column.
>
> Here is a patch, that improves this a little bit, by making sure, that
> saves a call to the getvvcol() function and does only call
> update_topline and a couple of similar functions when the count is 1.
>
> Here is a small benchmark using that patch:
> time vim -u NONE -N -c ':exe "norm! <nr>afoobar\<esc>:q!\<cr>"'
>
> <nr> Vim Patch
> 1000 3,6s 1,6s
> 2000 18,4s 6,4s
> 2500 29,5s 10,1s
> (I didn't even try to use some really large <nr>)
>
> As you can see, this seems to slow down exponentially. I could imagine,
> that this will make Vim unresponsive even when not using <nr>a but one
> only tries to append to a real long line.

Not as bad as exponential, but quadratic.
I just measured it on my laptop with & without
your patch:

nr before patch after patch
2000 0.619 sec 0.205 sec
4000 2.186 sec 0.734 sec
8000 8.565 sec 2.822 sec
16000 24.423 sec 11.215 sec

When n doubles, it's 4x slower, which means O(n^2)
with or without patch, but it's definitely faster with
your patch.

Dominique