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 (!!).
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).
--
--
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.
