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)?
--
Women are probably the main cause of free software starvation.
/// 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.
