GNU bug report logs - #50733
28.0.1; project-find-regexp can block Emacs for a long time

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 50733 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#50733: 28.0.1; project-find-regexp can block Emacs for a
 long time
Date: Fri, 24 Sep 2021 09:03:51 +0300

> From: Daniel Martín <mardani29 <at> yahoo.es>
> Cc: 50733 <at> debbugs.gnu.org,  dgutov <at> yandex.ru
> Date: Thu, 23 Sep 2021 22:42:32 +0200
> 
> >> Elapsed time: 36.087181s (8.067474s in 22 GCs)
> >> 
> >> Running the same search with ripgrep from the command line takes around
> >> 6 seconds.
> >
> > How many matches does that report?
> 
> ~70400 matches spread across ~3700 files.  Perhaps it's an extreme case
> (I used a generic search term, "color").  I tried a more specific search
> term ("clang analyzer") which returned 30 matches across 14 files.
> Here's the benchmark:
> 
> Elapsed time: 10.176629s (0.946311s in 2 GCs)

This means processing 70K lines of output takes 28 - 9 = 19 seconds,
which is the lion's share of the run time in those situations.  9 sec
to scan the files and 8 sec to GC.

> I guess the command could signal ongoing progress somehow, to assure the
>  user that Emacs is actually working and not frozen.

Currently, that's impossible, because we never return to the main loop
while we wait for the process to terminate, so no Lisp can run during
that time.  That'd require to add a new hook, which the call-process
machinery would call while we wait, or maybe even a C-level function
to report the progress directly.  Shouldn't be too hard, I think, see
wait_for_termination.

Previous Next

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