Yegappan Lakshmanan wrote:
> On Sat, May 7, 2016 at 2:42 PM, Ramel Eshed <rame...@gmail.com> wrote:
> > Hi All,
> >
> > Thanks to Bram and his recent work on channels, I have a preliminary
> > version of an asynchronous grep plugin which lets you work with the
> > available results while grep is still running. I would like to take
> > advantage of this relatively short script to raise some issues and
> > thoughts I have. The plugin can be found at
> > https://github.com/ramele/agrep.
> >
>
> > 2. Quickfix issues
> > a. As long as there are not too many matches and
> > the quickfix window is closed you can fire up a search and start
> > jumping to the available matches while the search is still running
> > using the quickfix navigation commands (:cn, for example). The problem
> > is when the quickfix window is opened while the search is active =E2=80=
> =93
> > here there is a serious performance issue, and Vim hangs for a while.
> > You can see this by running :copen and then :Agrep. Choose a search
> > that will generate many results (> 1000).
> >
> > b. As the matches rate becomes higher, Vim will become
> > unresponsive. It may happen for short intervals or it can hangs for a
> > while (for very high rate). By =E2=80=9Crate=E2=80=9D I simply mean to
> > number_of_matches / sec. To compare, the performance is much better
> > with the agrep window.
> >
> > As I understand (and please correct me if I=E2=80=99m wrong) when using
> > setqflist() to create a new list or add items to the current list, Vim
> > reads all the buffers (as an unlisted buffers) in order to set the
> > hidden marks. I think that this is the reason of the slowness I=E2=80=99m
> > experiencing. If I'm right, maybe the way Vim loads the buffers of the
> > qf list should be changed so buffers will be loaded only when they're
> > been accessed and not when they're added to the list. What do you
> > think?
> >
>
> When adding a new entry to the quickfix list, a search is made to locate
> the last entry. I think, this is the reason for the long processing time.
> To confirm this, I created a test script to add 100000 entries to the
> quickfix list. It took almost 120 seconds to complete. After I changed
> the quickfix code to keep track of the last entry, this reduced to 2 second=
> s.
> Can you try using the attached patch?
Is finding the end of the list really that slow?
If this helps, I would propose to set qf_last in qf_add_entry() and drop
the use of qfprev. That keeps the logic of updating the last entry in
one place, and we could drop the "last element points to itself"
perhaps. And "first element points to itself". Using NULL makes more
sense.
--
How To Keep A Healthy Level Of Insanity:
17. When the money comes out the ATM, scream "I won!, I won! 3rd
time this week!!!!!"
/// 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.
