GNU bug report logs - #26710
project-find-regexp blocks the UI

Previous Next

Full log

Message #34 received at 26710 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: hariharanrangasamy <at> gmail.com, 26710 <at> debbugs.gnu.org
Subject: Re: bug#26710: Fwd: 25.2; project-find-regexp makes emacs use 100% cpu
Date: Tue, 02 May 2017 10:15:15 +0300

> Cc: hariharanrangasamy <at> gmail.com, 26710 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 2 May 2017 00:46:25 +0300
> 
> See commit c99a3b9. Please take a look at 
> xref--regexp-syntax-dependent-p specifically, and see if any significant 
> false negatives come to mind.

Can you explain the significance of xref--regexp-syntax-dependent-p's
tests?  I don't know enough about xref to grasp that just by looking
at the changes.

> With this, project-find-regexp for 'emacs' finally completes in ~10 
> seconds on my machine.

It takes about 15 here (and 45 in an unoptimized build).  I guess this
slowdown is expected, since this is a 32-bit build --with-wide-int, so
should be 30% slower than with native ints.

I don't remember the original timings, but this looks like a good
improvement, thanks.

> >> What we _can_ manage to run in parallel, in the find-grep process in the
> >> background, and the post-processing of the results in Elisp.
> > 
> > Yes, you can -- if you invoke find-grep asynchronously and move the
> > processing of the hits to the filter function.
> 
> Yes, these parts are necessary either way. What I was describing would 
> go on top of them, as an abstraction.

If the processing is in filter and sentinel functions, I'm not sure we
will need any further speedups, because the UI will remain responsive.

> > But that doesn't need
> > to involve threads, and is being done in many packages/features out
> > there, so I'm not sure what did you ask me to do with this.
> 
> I imagined that the xref API that allows this kind of asynchronous 
> results might look better and more readable if it's implemented with 
> threads underneath.

If you need advice for how to implement something like that, I can try
helping with threads.

> The main thing to understand is the xref API, not the internals of the 
> package.

Well, I lack that understanding as well.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.