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 -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.