Christian Brabandt <[email protected]> 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 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
