100000ii<esc>

[Eli the Bearded]

Prompted by a challenge here:

https://fivethirtyeight.com/features/pirates-monkeys-and-coconuts-oh-my/

(Near the bottom of the page, in the answers to the previous challenge
dealing with editors.)

I tried inserting a million letter "i"s into a new buffer with vim. Oh,
how insanely slow it was. I hit control-C after 20ish seconds and it was
up to about 30,000 letters inserted. I tried two different builds of vim.

Then, for comparison, I used nvi and elvis. Nvi does it too fast to measure by
wall clock. Elvis was under 5 seconds.

vim: VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 24 2016 16:44:48)
(This version is the package one for my Ubuntu release.)


vim: VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 13 2018 17:19:45)
nvi: Version (1.81.6-2013-11-20nb3) The CSRG, University of California, Berkeley.
elvis: elvis 2.2.0
(These three were all tried on NetBSD, the Vim and Elvis compiled from source,
the Nvi the system /usr/bin/vi.)

I don't think blinding fast is entirely necessary, but not even half-way
there in 20 seconds is Not Good.

Elijah

[Keith Edmunds]

Optimising vim for a use case that will never exist in real life seems, well, pointless.

Why is this important to you?

[Dominique Pellé]

I would not say that it's a useless use case.
It may be a rare case but it can happen. When it happens,
insertion can take so much time that user may have to
press CTRL-C.

I recall that this was discussed earlier but I can't find the thread.
It's probably not simple to fix so it has not been fixed yet.

Performance looks currently quadratic since time is multiplied
by ~ 4 each time we double the insert count:

$ /usr/bin/time ./vim --clean -c 'norm 5000ix' -c 'q!'
0.13user 0.00system 0:00.13elapsed 99%CPU (0avgtext+0avgdata
17532maxresident)k
0inputs+8outputs (0major+1292minor)pagefaults 0swaps

$ /usr/bin/time ./vim --clean -c 'norm 10000ix' -c 'q!'
0.72user 0.00system 0:00.73elapsed 99%CPU (0avgtext+0avgdata
17684maxresident)k
0inputs+8outputs (0major+1301minor)pagefaults 0swaps

$ /usr/bin/time ./vim --clean -c 'norm 20000ix' -c 'q!'
3.37user 0.00system 0:03.37elapsed 99%CPU (0avgtext+0avgdata
17744maxresident)k
0inputs+8outputs (0major+1311minor)pagefaults 0swaps

$ /usr/bin/time ./vim --clean -c 'norm 40000ix' -c 'q!'
14.05user 0.00system 0:14.06elapsed 99%CPU (0avgtext+0avgdata
17592maxresident)k
0inputs+8outputs (0major+1318minor)pagefaults 0swaps

In theory, it could be done quickly in O(n).

Regards
Dominique

[François Ingelrest]

On Tue, 15 May 2018 at 10:40, Dominique Pellé wrote:
> In theory, it could be done quickly in O(n).

Actually pasting the character with 1000000p is super fast, so 1000000ix
can surely be optimized.

[Chr. von Stuckrad]

On Tue, 15 May 2018, Keith Edmunds wrote:

> Why is this important to you?

Is this the same 'slowness' as in reading and moving around in
big, especially binary, files?

It seems, as if 'something which needs line endings' is slowing vim
down (over?)proportionally to the length of the 'unbroken' line.

So if you insert 'lots of chars' by vim itself, it might run
into the same problem?

I did not check, I'm just curious, because I just had to kill
a vim-session which was so slow, that I didn't have the time
to wait for reaching the next command ...

I needed 'a viewer for an big unknown file', used 'view' and
after a jump ... waited ... ... ... until had to leave.

Stucki


--
Christoph von Stuckrad * * | also XMPP = |Mail <stu...@mi.fu-berlin.de> \
Freie Universitaet Berlin |/_*| 'jabber' via|Tel(Mo.,Mi.):+49 30 838-75 459|
IT Mathematik & Informatik|\ *|stucki@jabber| (Di,Do,Fr):+49 30 77 39 6600|
Takustr. 9 / 14195 Berlin * * |.fu-berlin.de|Fax(home): +49 30 77 39 6601/

[Bram Moolenaar]

There is an old entry in the todo list to do profiling on this, to find
out what takes so much time. Apparently nobody bothered to look into
this yet.

--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~

/// 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 ///

[Christian Brabandt]

On Di, 15 Mai 2018, Bram Moolenaar wrote:

> There is an old entry in the todo list to do profiling on this, to find
> out what takes so much time. Apparently nobody bothered to look into
> this yet.

I measured it once and I think the problem was the call to getvcol().

More details in this old thread:
https://groups.google.com/d/msg/vim_dev/LbuDtft5488/ZZBKYZUnIUQJ

Best,
Christian
--
O Freund, der Mensch ist nur ein Tor,
stellt er sich Gott als seines Gleichen vor.
-- Johann Wolfgang von Goethe (Der ewige Jude)

[Bram Moolenaar]

Christian wrote:

> On Di, 15 Mai 2018, Bram Moolenaar wrote:
>
> > There is an old entry in the todo list to do profiling on this, to find
> > out what takes so much time. Apparently nobody bothered to look into
> > this yet.
>
> I measured it once and I think the problem was the call to getvcol().
>
> More details in this old thread:
> https://groups.google.com/d/msg/vim_dev/LbuDtft5488/ZZBKYZUnIUQJ

Ah yes, that helped a bit. I think it's still not good enough.

--
Yesterday, all my deadlines seemed so far away
now it looks as though it's freeze in four days
oh I believe in cvs..
[ CVS log "Beatles style" for FreeBSD ports/INDEX, Satoshi Asami ]