On Monday, July 11, 2016 at 12:33:28 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
>
> > On Sunday, July 10, 2016 at 8:23:15 PM UTC+3, Bram Moolenaar wrote:
> > > Lcd wrote:
> > >
> > > > [...]
> > > > > > Currently an error item from loclist looks like this:
> > > > > >
> > > > > > {
> > > > > > 'lnum': 148,
> > > > > > 'bufnr': 1,
> > > > > > 'col': 7,
> > > > > > 'valid': 1,
> > > > > > 'vcol': 0,
> > > > > > 'nr': -1,
> > > > > > 'type': 'W',
> > > > > > 'pattern': ',
> > > > > > 'text': '(3) CodeLayout::ProhibitHardTabs: Hard tabs
> > > > > > used (See page 20 of PBP)'
> > > > > > }
> > > > > >
> > > > > > If I want to place a sign at the file, I can do this:
> > > > > >
> > > > > > sign place 12345 line=148 name=SyntasticError buffer=1
> > > > > >
> > > > > > This works regardless if the fuffer is hidden or not, and can be
> > > > > > done before the user jumps to the error.
> > > > > >
> > > > > > How would I do the same starting only with a filename, assuming
> > > > > > the user hasn't jumped to the error yet, or opened the file?
> > > > >
> > > > > Yeah, when using getqflist() or getloclist() we currently only get the
> > > > > "bufnr". This I would think, by default the file name is changed to
> > > > > a buffer at that point. Since this can be expensive, we could add an
> > > > > argument to return the file name instead of a buffer number.
> > > > >
> > > > > So we have a dilemma: For the plugin that intentionally avoids
> > > > > creating a buffer for every error, it can have these extra options
> > > > > to make it (a lot) faster. But as soon as another plugin comes into
> > > > > play, which depends on the buffer, things fall back to how they were.
> > > > > I think that is unavoidable.
> > > >
> > > > So functions that create qflists and loclists (make, cgetexpr etc.)
> > > > would create them with filenames, and it would be up to getqflist()
> > > > and getloclist() to request the corresponding files to be loaded
> > > > into buffers (with the default being to load files, for backwards
> > > > compatibility). Also, the results could be cached. That would work
> > > > nicely, and it wouldn't be slower for plugins that want old-style
> > > > qflists and loclists.
> > >
> > > I have optimized the quickfix code with the last few patches. It's a
> > > lot faster now, especially when there are several matches in the same
> > > file. Let's see if Ramel thinks this is good enough, then we don't need
> > > to add the workaround.
> > >
> > I've checked 2 test cases:
> >
> > 1) Adding many (80,000+) entries to quickfix list: here I see huge
> > improvement -from 6.76 seconds to 0.38 (!!).
>
> Glad to hear my changes were effective.
>
> > 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.
--
--
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.
