On 20/07/2013 10:13, LCD 47 wrote:
On 19 July 2013, Mike Williams <mike.willi...@globalgraphics.com> wrote:
On 19/07/2013 15:52, Mike Williams wrote:
On 19/07/2013 12:18, Dimitar DIMITROV wrote:
Hi,
Did a search on the vim_dev archives but couldn't find anything
related to this. Sorry if this is redundant. Basically vim is
exponentially slow after 1000000iHello <esc> as mentionned in this
link:
http://www.galexander.org/vim_sucks.html
A quick run over with a profiler seems to show most of the time is
being spent in vim_strchr() called from has_format_option(), called
>from internal_format(). If I first do :set paste then it is a lot
quicker - for 4000iHello<ESC> it goes from 16s down to 1s.
[...]
Textwidth. Darn sight quicker with it set to 0, wish I had
remembered that. Another factor of ~2 quicker for my final times,
16000iHello<ESC> now takes ~4s.
[...]
Right, what you're seeing here is Vim backtracking to find a blank
to split that N * "Hello" line. Since there is no such blank, you get
len("Hello") * N * (N + 1) / 2 failed comparisons, which is exactly the
O(N^2) behaviour claimed in the article mentioned above.
If you replace your test by, say, "16000iHello <ESC>" (with a space
after "Hello"), you get linear behaviour, namely len("Hello") * N failed
comparisons.
I believe this can be fixed with a counter that means something
along the lines of: "this line is longer than &tw, and it has no
breaking point for the first X characters". Then X would be updated
every time more text is appended to that line.
Yup to all that. And there is another O(n^2) operation is getvcol()
rescanning the line after each insert.
On 19 July 2013, Marc Weber <marco-owe...@gmx.de> wrote:
Let's discuss the use case, first. Is there one ?
Yes, there is: you run through that piece of code every time you
press "p" to paste text. It hits you particularly hard when you edit
files with very long lines.
If not let's forgett about it ..
[...]
Perhaps we should try to understand the problem before dismissing it
as harmless?
Indeed. Part of the problem is that most computers these days have
ridiculous amounts of processing power and storage that slow algorithms
for small to medium amounts of data appear near instantaneous. On say
an Atom or Arm based netbook then the problem becomes more apparent.
Getting a faster machine is not always the solution.
Mike
--
Born naked, wet and hungry... and it gets worse?
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
