From: Dmitry Gutov <dgutov@yandex.ru>
To: "Mattias Engdegård" <mattiase@acm.org>, "Eli Zaretskii" <eliz@gnu.org>
Cc: larsi@gnus.org, 49836@debbugs.gnu.org, juri@linkov.net
Subject: bug#49836: Support ripgrep in semantic-symref-tool-grep
Date: Sun, 19 Sep 2021 00:48:24 +0300 [thread overview]
Message-ID: <b36e5285-fa32-4482-a1a8-a2c4872c9c7b@yandex.ru> (raw)
In-Reply-To: <30E69411-791E-485B-AFFF-61E7965C6238@acm.org>
On 18.09.2021 17:18, Mattias Engdegård wrote:
> 18 sep. 2021 kl. 16.14 skrev Eli Zaretskii<eliz@gnu.org>:
>
>>> If the actual command (ripgrep or something else) takes zero seconds, what if anything prevents a crisp snappy response from Emacs?
>> The sub-process communications infrastructure, of course.
> Yes, very likely, but also post-processing the output from the search process (matching, sorting, etc) and preparing it for display. It would be interesting to see a break-down and to see what if anything can be down to make to go faster.
>
Before you dig in with OS-level debugger, here are things to try to
narrow down the problems:
- Do the search for a common term (many matches).
- Do the search for a rare term (with 1-2 matches).
See how the inside/outside timings compare. I'm guessing the latter case
should be snappy, with a relatively small ratio. Whatever overhead Emacs
has, will probably be on the sub-process infrastructure.
To investigate the former case (many matches), I suggest starting with
'benchmark-progn'.
Wrapping the 'process-file' call will measure the shell invocation and
getting the output into the buffer.
diff --git a/lisp/cedet/semantic/symref/grep.el
b/lisp/cedet/semantic/symref/grep.el
index 53745b429a..7db5e79c91 100644
--- a/lisp/cedet/semantic/symref/grep.el
+++ b/lisp/cedet/semantic/symref/grep.el
@@ -163,8 +163,9 @@ semantic-symref-perform-search
(let ((cmd (semantic-symref-grep-use-template
(directory-file-name (file-local-name rootdir))
filepattern grepflags greppat)))
- (process-file semantic-symref-grep-shell nil b nil
- shell-command-switch cmd)))
+ (benchmark-progn
+ (process-file semantic-symref-grep-shell nil b nil
+ shell-command-switch cmd))))
(setq ans (semantic-symref-parse-tool-output tool b))
;; Return the answer
ans))
Measuring the subsequent semantic-symref-parse-tool-output call can also
show something, but it's usually fast.
Wrapping the xref--convert-hits call alone inside
xref-references-in-directory should be more interesting: its work is
less trivial. I don't know how much further it can be optimized, but
help is welcome, of course.
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 69cabd0b5a..ab0476b2bb 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -1548,9 +1548,11 @@ xref-references-in-directory
(inst (semantic-symref-instantiate :searchfor symbol
:searchtype 'symbol
:searchscope 'subdirs
- :resulttype 'line-and-text)))
- (xref--convert-hits (semantic-symref-perform-search inst)
- (format "\\_<%s\\_>" (regexp-quote symbol)))))
+ :resulttype 'line-and-text))
+ (search-hits (semantic-symref-perform-search inst)))
+ (benchmark-progn
+ (xref--convert-hits search-hits
+ (format "\\_<%s\\_>" (regexp-quote symbol))))))
(define-obsolete-function-alias
'xref-collect-references
next prev parent reply other threads:[~2021-09-18 21:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-02 21:05 bug#49836: Support ripgrep in semantic-symref-tool-grep Juri Linkov
2021-08-03 8:10 ` Juri Linkov
2021-08-04 3:14 ` Dmitry Gutov
2021-08-04 21:23 ` Juri Linkov
2021-08-05 3:03 ` Dmitry Gutov
2021-08-06 0:35 ` Juri Linkov
2021-08-07 14:12 ` Dmitry Gutov
2021-09-18 13:53 ` Mattias Engdegård
2021-09-18 14:14 ` Eli Zaretskii
2021-09-18 14:18 ` Mattias Engdegård
2021-09-18 14:25 ` Eli Zaretskii
2021-09-18 21:48 ` Dmitry Gutov [this message]
2021-09-18 23:53 ` Dmitry Gutov
2021-09-19 0:21 ` Jim Porter
2021-09-19 10:11 ` Mattias Engdegård
2021-09-20 0:14 ` Dmitry Gutov
2021-09-20 5:09 ` Jim Porter
2021-09-20 17:04 ` Dmitry Gutov
[not found] <83h7elbzo3.fsf@gnu.org>
[not found] ` <7b0409e3-fc88-b34e-9365-25356bb85859@yandex.ru>
[not found] ` <83bl4tbxyu.fsf@gnu.org>
[not found] ` <12215e07-af4e-2db7-1869-16ac92feb806@yandex.ru>
[not found] ` <8335q5bt9b.fsf@gnu.org>
[not found] ` <ee8b7d7f-abd1-42fc-a273-819ccef3c4e7@yandex.ru>
2021-09-17 16:07 ` Juri Linkov
2021-09-17 16:24 ` Lars Ingebrigtsen
2021-09-18 18:37 ` Juri Linkov
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b36e5285-fa32-4482-a1a8-a2c4872c9c7b@yandex.ru \
--to=dgutov@yandex.ru \
--cc=49836@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=juri@linkov.net \
--cc=larsi@gnus.org \
--cc=mattiase@acm.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).