On Jan 21, 9:56 am, Bram Moolenaar <[email protected]> wrote:
> Sounds good. I'll add this in the todo list.
There is already an item about readfile() and realloc in the todo
list:
8 When editing a file with extremely long lines (e.g., an
executable), the
"linerest" in readfile() is allocated twice to be able to copy
what was
read so far. Use realloc() instead? Or split the line when
allocating
memory fails and "linerest" is big (> 100000)?
I read this as worrying about the case where there's limited memory,
and the copy from readfile's working string to store in the list. I
suspect that the item was really prompted by the problem of the O(n^2)
growth strategy causing poor performance, which hit me in my use of
the yank ring plugin.
I was going to consider realloc soon, but have worked to establish
correctness first. I get a similar speed up as Dominique using a 50%
growth factor for the working string, and I was thinking about how
realloc could be applied to avoid copying a very long line. I wonder
how good realloc implementations are at reducing the length of
strings.
The old code's handling of allocation failures is haphazard, or at
least I can't see a clear outcome if an allocation fails. I would
like to test with such failures; what's an easy way to do this on
Linux? And can we write tests for this kind of problem?
Regards, John
--
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
