On Thursday, July 14, 2016 at 11:34:36 PM UTC+3, Bram Moolenaar wrote:
> 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.

Yes. It is very fast now.

> 
> > 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.

Raspunde prin e-mail lui