On Friday, September 12, 2014 3:52:30 PM UTC+12, John Little wrote:
> On Friday, September 12, 2014 2:35:40 AM UTC+12, Charles Campbell wrote:
> > Have you tried profiling?
>
> Just did ...
Then I found gprof -l. It's first couple of lines say
% cumulative self self total
time seconds seconds calls ns/call ns/call name
85.41 48.36 48.36 ml_updatechunk
(memline.c:5035 @ 4d368d)
7.86 52.81 4.45 ml_updatechunk
(memline.c:5033 @ 4d36eb)
These are in a for loop:
for (curline = 1, curix = 0;
curix < buf->b_ml.ml_usedchunks - 1
&& line >= curline + buf->b_ml.ml_chunksize[curix].mlcs_numlines;
curix++)
{
curline += buf->b_ml.ml_chunksize[curix].mlcs_numlines;
}
It appears that vim is walking its list of chunks (where it keeps lines) from
the beginning, for each line of text already read when it changes encoding. I
suspect there's several performance opportunities here:
1) The "last" chunk used by ml_updatechunk is saved in static variables. This
mechanism seems to be not working.
2) In my case the vast majority of lines haven't changed, there's no need to
update anything.
3) Something faster than a linear search might be possible.
Regards, John Little
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
