On 22/08/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Brad Beveridge wrote:
<SNIP>
Thanks for making this patch.
No problem - it happened to be my particular itch :)
I wonder how you create a new line. Using the old mechanism you mostly
end up reallocating the line at the next insert. Allocating a bit of
room to anticipate further appends would be more efficient.
I'm sorry, I don't understand quite what you mean with that comment.
Do you mean "if you only used ml_append_string, how do new lines ever
get created?" If you do mean that, then the answer is: new lines need
to be created by an upper level function. I have an upper level
"append_char" function that is more or less:
void append_char (buf, char) {
static uchar string[2] = {0};
curbuf = buf;
if (char == '\n')
ml_append // create a new line
else
{
string[0] = char;
ml_append_string (string)
.......
The reason that I didn't do new line creation in append_string is that
you would need to check all incoming strings for newlines, the upper
level layers can better do this check because they have more
information about the incoming string - they could know it will never
contain newlines.
Also, for appending to a different line than before you copy the line
twice. You can avoid that by using vim_strnsave() instead of
vim_strsave() and reserving space for new characters right away.
Yes, this is a slight inefficiency. The main reason that I did this
was that I wanted all the code to do with re-allocation in the same
place, ie the next if block. Looking at the code again now, the
solution is probably to not copy in the "cache miss" code, where we
flush - just do
curbuf->b_ml.ml_line_ptr = ml_get(lnum);
Cheers
Brad
