From: "Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 50733@debbugs.gnu.org
Subject: bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time
Date: Wed, 22 Sep 2021 23:58:42 +0200 [thread overview]
Message-ID: <m1fstwl1bh.fsf@yahoo.es> (raw)
In-Reply-To: <03aa81b5-6077-c35c-1a5f-ec4d867b59ac@yandex.ru> (Dmitry Gutov's message of "Wed, 22 Sep 2021 22:09:43 +0300")
Dmitry Gutov <dgutov@yandex.ru> writes:
>
> IIRC you are using macOS. I received another report recently that
> find/grep based tooling, and project-find-regexp in particular, are
> pretty slow on that OS.
Yes, this is on macOS.
>
> When you say "block for a long time", how long are we talking about?
>>
> To try it, evaluate
>
> (benchmark 1 '(project-find-regexp "new-collection"))
I usually work on a monorepo with ~67000 tracked files (many of them big
binary files). Here's what I get when using ripgrep as the xref search
program:
Elapsed time: 36.087181s (8.067474s in 22 GCs)
Running the same search with ripgrep from the command line takes around
6 seconds.
>
> Another benchmark to try is
>
> (benchmark 1 '(project-files (project-current)))
Elapsed time: 1.590223s (0.432372s in 1 GCs)
Here's an ELisp profile of the first benchmark:
8696 78% - command-execute
8696 78% - call-interactively
8493 76% - funcall-interactively
8480 76% - eval-expression
8479 76% - eval
8479 76% - project-find-regexp
8227 74% - xref--show-xrefs
8227 74% - xref--show-xref-buffer
5584 50% - #<compiled 0x140b5a40100bafc6>
5584 50% - apply
5584 50% - project--find-regexp-in-files
5574 50% - xref-matches-in-files
3016 27% - xref--convert-hits
3000 27% - mapcan
2992 27% - #<compiled -0x6cdcd56218925c3>
2734 24% - xref--collect-matches
2094 18% - xref--collect-matches-1
800 7% + xref-make-match
774 7% + xref-make-file-location
104 0% xref--find-file-buffer
80 0% file-remote-p
51 0% xref--regexp-syntax-dependent-p
906 8% + xref--process-file-region
331 2% sort
1413 12% + xref--analyze
1230 11% + xref--show-common-initialize
249 2% + project-files
3 0% + project-current
9 0% + minibuffer-complete
4 0% + execute-extended-command
203 1% + byte-code
2314 20% - ...
2314 20% Automatic GC
27 0% + timer-event-handler
The search time is reduced when I use a more specific search term,
presumably because the number of results is lower and the Elisp
post-processing takes less time. Here's what I got, for example, when I
search for something with results from only one file:
Elapsed time: 6.859815s (0.864738s in 2 GCs)
Compared to the time taken by the same query from the command line
(6.5s) shows that the Elisp post-processing time is probably negligible
in this scenario.
next prev parent reply other threads:[~2021-09-22 21:58 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m1h7edq7sc.fsf.ref@yahoo.es>
2021-09-22 9:27 ` bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-22 19:09 ` Dmitry Gutov
2021-09-22 21:58 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-09-22 23:09 ` Dmitry Gutov
2021-09-23 17:41 ` Dmitry Gutov
2021-09-23 21:17 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-23 22:40 ` Dmitry Gutov
2021-09-24 6:34 ` Eli Zaretskii
2021-09-24 7:02 ` Juri Linkov
2021-09-24 10:43 ` Eli Zaretskii
2021-09-24 15:30 ` Juri Linkov
2021-09-24 16:08 ` Eli Zaretskii
2021-09-24 9:00 ` Gregory Heytings
2021-09-24 11:00 ` Eli Zaretskii
2021-09-24 11:43 ` Dmitry Gutov
2021-09-24 13:18 ` Gregory Heytings
2021-09-24 14:20 ` Eli Zaretskii
2021-09-24 15:50 ` Dmitry Gutov
2021-09-24 16:18 ` Eli Zaretskii
2021-09-24 16:22 ` Dmitry Gutov
2021-09-24 16:24 ` Gregory Heytings
2021-09-24 17:49 ` Eli Zaretskii
2021-09-24 17:52 ` Gregory Heytings
2021-09-24 18:48 ` Eli Zaretskii
2021-09-24 21:49 ` Gregory Heytings
2021-09-25 6:26 ` Eli Zaretskii
2021-09-27 0:43 ` Gregory Heytings
2021-09-27 5:14 ` Eli Zaretskii
2021-09-27 9:23 ` Gregory Heytings
2021-09-27 11:48 ` Eli Zaretskii
2021-09-27 12:25 ` Gregory Heytings
2021-09-27 12:44 ` Eli Zaretskii
2021-09-27 19:36 ` Gregory Heytings
2021-09-28 5:17 ` Eli Zaretskii
2021-09-28 8:23 ` Gregory Heytings
2021-09-27 12:58 ` Dmitry Gutov
2021-09-27 13:05 ` Eli Zaretskii
2021-09-27 19:37 ` Gregory Heytings
2021-09-24 18:17 ` Dmitry Gutov
2021-09-24 18:51 ` Eli Zaretskii
2021-09-24 11:40 ` Dmitry Gutov
2021-09-24 12:02 ` Eli Zaretskii
2021-09-24 12:22 ` Dmitry Gutov
2021-09-24 13:06 ` Eli Zaretskii
2021-09-24 14:05 ` Dmitry Gutov
2021-09-23 6:13 ` Eli Zaretskii
2021-09-23 20:42 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-23 22:18 ` Dmitry Gutov
2021-09-24 6:03 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1fstwl1bh.fsf@yahoo.es \
--to=bug-gnu-emacs@gnu.org \
--cc=50733@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=mardani29@yahoo.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.