Ramel Eshed wrote:
> > 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.
Please try this again after patch 7.4.2036. The lookup of a buffer by
number should be a lot faster.
> 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.
A user is not really expected to deal with buffer numbers, there are
many other ways to find the right buffer.
In the other thread the discussion about the disadvantages of not
storing a file as a buffer were relevant. Also, adding an option to all
quickfix commands that add an entry is not nice.
There are other ways to end up with lots of buffers, it is good to make
that fast anyway.
--
GALAHAD: No, please. Please! I can defeat them! There's only a hundred.
GIRLS: He will beat us easily. We haven't a chance.
"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.
