On Monday, May 30, 2016 at 5:11:57 AM UTC+3, [email protected] wrote: > Hi, > > On Sat, May 7, 2016 at 2:42 PM, Ramel Eshed <[email protected]> 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 – > > 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 “rate” 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’m 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’m > > 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 seconds. > Can you try using the attached patch? > > - Yegappan
Hi Yegappan, Thanks for checking this. I didn't see a noticeable improvement, at least regarding to my second issue (b) - The cursor is still not fully responsive in my test case (search which returns 10000 results and add each one to the qf list on the fly). It also does not solve the first issue. Also, I noticed a very strange issue (which also exists without your patch, but I think that your patch makes it even worse): When I run my search command without using the quickfix list I get the 10000 results in about 2.2 seconds (and it's also non blocking of course -pretty nice :)). But -when I run this search after using the quickfix list the performance (of my search command, which is not related to the quickfix mechanism) becomes very bad. Actually, the performance degrades in a correlation with how many times I used the quickfix before. Example: :Agrep -r <pattern> <directory> - This is my search command. It returns all the results in 2.2 seconds (no quickfix list here). But: :grep -r <pattern> <directory> " regular grep that uses the quickfix list and then - :Agrep -r <pattern> <directory> - Here, my Agrep command takes ~4 seconds And :grep -r <pattern> <directory> :grep -r <pattern> <directory> :grep -r <pattern> <directory> :Agrep -r <pattern> <directory> - Now Agrep takes ~7 seconds. Any idea what is going on here? -- -- 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.
