all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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.