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.
Can part of the conditional for the while() looking for a position to
break at in internal_format() (line 6186) be hoisted out as constant for
the duration of the outer while loop? Thinking of the control
expression clauses:
(!fo_ins_blank && !has_format_option(FO_INS_VI))
|| (flags & INSCHAR_FORMAT)
This doesn't change the cost of the insert function but removes a large
constant factor.
Re-running with the profiler then has the time spent in in plines_win()
and its children, which is a little surprising since nothing is
displayed until all the inserts have been done. Turning wrap off speeds
things up again. With ":set paste" then 10000iHello<ESC> takes ~9s.
With ":set paste nowrap" then 10000iHello<ESC> takes ~2s and
16000iHello<ESC> takes ~7s, or doing 4x the first test in less than half
the time Re-enabling warp afterwards is instantaneous yet costs 7s for
no gain during the repeated insert operation.
So it looks like all the extra work VIM does for formatting inserted
text and displaying it is where the time is going, sometimes not
efficiently and sometimes for no actual benefit. Then again, is it
reasonable to expect 25000iString<ESC> to be a typical operation (up
there with editing 1GB log files)?
HTH - TTFN
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.
Obviously the fact that these settings has such an influence for large
repetition counts for single line updates is not documented anywhere.
Then again there are better ways of generating a 4MB file containing a
single line of data - just cos you hammer a nail into wood with a
spanner doesn't mean you should.
Mike
--
Sympathy: What one woman offers another in exchange for the details.
--
--
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.
