Ramel Eshed wrote:
[...]
> > > 2) The following script:
> > >
> > > func! Setbv()
> > > let rt = reltime()
> > > for i in range (1, 40000)
> > > call setbufvar('mybuf', 'myvar', 2)
> > > endfor
> > > echo reltimestr(reltime(rt))
> > > endfunc
> > >
> > > Before setting any quickfix list it takes 0.22s. After setting a
> > > quickfix list with 80000 entries it takes 6.5 seconds, which is
> > > actually worse than how it was before the last patches (it took then
> > > 3.56s).
> >
> > Strange. Oh, perhaps it's because this "mybuf" is near the start of the
> > buffer list? I reversed the search order, thinking that there is a
> > higher chance of searching for a newer buffer.
> >
> > You can try changing buflist_findname_stat() from:
> >
> > for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
> >
> > To:
> >
> > for (buf = firstbuf; buf != NULL; buf = buf->b_next)
> >
> > You can also try adding a new buffer after filling the quickfix list and
> > calling setbufvar() on that one.
> >
> > Anyway, how relevant is calling setbufvar() 40000 times?
> > Can you use a buffer number instead of a name (would be more reliable
> > anyway)?
> >
> When adding the buffer after filling the quickfix list it takes 3.7s
> instead of 6.5. When using buffer number it takes 0.15s if the buffer
> is the last one, but it's still slow (3.1s) if the buffer was created
> before the list.
>
> I not sure if this specific use case is relevant (It was relevant to
> me, before I made some optimizations to my script...), but I'm sure
> that there are many other operations which involve searching in the
> buffers list that can slow down Vim when there are many quickfix
> items.
> Anyway, I don't think that saving all the buffers of the search
> results by default is a good idea. This way you can easily find
> yourself dealing with 4 digits buffer numbers while you have only few
> that you're actually working on.
The option to store the file name as a string, not in a buffer, has been
discussed, but it has disadvantages. At least it adds another option,
with consequences for what data is stored in the error lists.
An alternative is to create an index for the buffers. Instead of going
through the list linearly it would use a dictionary to lookup by name or
by number. This means adding and removing a buffer becomes more
expensive. But lookups become much faster.
Actually, lookup by name using a hash table won't really work, at least
not for Unix, because the same file can have more than one name.
I would expect lookup by number to be more frequent anyway.
--
They now pass three KNIGHTS impaled to a tree. With their feet off the
ground, with one lance through the lot of them, they are skewered up
like a barbecue.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
