Package: emacs;
Reported by: Eli Zaretskii <eliz <at> gnu.org>
Date: Tue, 5 Apr 2016 15:17:02 UTC
Severity: normal
Found in version 25.0.92
Fixed in version 25.1
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: help-debbugs <at> gnu.org (GNU bug Tracking System) To: Dmitry Gutov <dgutov <at> yandex.ru> Cc: tracker <at> debbugs.gnu.org Subject: bug#23223: closed (25.0.92; Can xref-find-references be sped up?) Date: Tue, 12 Apr 2016 18:50:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Tue, 12 Apr 2016 21:49:14 +0300 with message-id <1d635548-1fe3-ea72-4c98-6f787d7438b0 <at> yandex.ru> and subject line Re: bug#23223: 25.0.92; Can xref-find-references be sped up? has caused the debbugs.gnu.org bug report #23223, regarding 25.0.92; Can xref-find-references be sped up? to be marked as done. (If you believe you have received this mail in error, please contact help-debbugs <at> gnu.org.) -- 23223: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23223 GNU Bug Tracking System Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Eli Zaretskii <eliz <at> gnu.org> To: bug-gnu-emacs <at> gnu.org Subject: 25.0.92; Can xref-find-references be sped up? Date: Tue, 05 Apr 2016 18:16:04 +0300With an ID database present in the Emacs top-level directory, do this: emacs -Q C-x C-f src/buffer.c RET C-u 1316 M-x goto-char RET You should now see point on "current_buffer". Now: M-x xref-find-references RET RET When prompted for the project directory, remove the "src/" part, to specify the root of the Emacs tree, and type RET. This takes around 13 sec here, although the corresponding 'lid' command: lid --result=grep -l -w current_buffer takes only 0.07 sec. The important part of the Lisp-level profile appears below. It looks like we are visiting each match of each file in the list of matches, and that takes most of the time. Can this be avoided somehow? The 'lid' command already includes all the matches in Grep format, so why are we visiting each match, when the information should be already available? - command-execute 833 92% - call-interactively 833 92% - funcall-interactively 830 92% - execute-extended-command 830 92% - command-execute 826 91% - call-interactively 815 90% - funcall-interactively 813 90% - xref-find-references 813 90% - xref--find-xrefs 813 90% - xref-backend-references 800 88% - cl-mapcan 788 87% - apply 788 87% - cl-mapcar 788 87% - mapcar 788 87% - #<compiled 0x200000000842dea0> 788 87% - xref-collect-references 788 87% - cl-mapcan 770 85% - apply 770 85% - cl-mapcar 770 85% - mapcar 770 85% - #<compiled 0x20000000084ea738> 770 85% - xref--collect-matches 728 80% - semantic-find-file-noselect 556 61% - find-file-noselect 556 61% - find-file-noselect-1 519 57% - after-find-file 503 55% - normal-mode 499 55% - set-auto-mode 493 54% - set-auto-mode-0 488 54% - c-mode 488 54% - c-common-init 480 53% - mapc 473 52% - #<compiled 0x2000000001c06b28> 472 52% - c-neutralize-syntax-in-and-mark-CPP 466 51% - c-extend-font-lock-region-for-macros 205 22% - c-state-literal-at 205 22% - c-state-safe-place 199 22% - c-beginning-of-macro 3 0% back-to-indentation 3 0% c-syntactic-end-of-macro 1 0% c-syntactic-end-of-macro 9 1% c-neutralize-CPP-line 7 0% - c-beginning-of-macro 4 0% back-to-indentation 2 0% #<compiled 0x2000000001c06b00> 1 0% - c-basic-common-init 7 0% - c-set-style 4 0% - mapc 4 0% - #<compiled 0x2000000001ae61c0> 4 0% - c-set-style-1 2 0% - mapcar 2 0% #<compiled 0x2000000001ae53a0> 1 0% - run-mode-hooks 3 0% In GNU Emacs 25.0.92.75 (i686-pc-mingw32) of 2016-04-04 built on HOME-C4E4A596F7 Repository revision: f501116ea896b20f195f5c841e8770d7fe0418b9 Windowing system distributor 'Microsoft Corp.', version 5.1.2600 Configured using: 'configure --prefix=/d/usr --enable-checking=yes,glyphs --with-wide-int --with-modules 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS MODULES Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message dired format-spec rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote w32notify w32 multi-tty make-network-process emacs) Memory information: ((conses 16 93253 6020) (symbols 56 20721 0) (miscs 48 36 107) (strings 16 17749 6443) (string-bytes 1 439871) (vectors 16 12404) (vector-slots 8 429720 3894) (floats 8 162 70) (intervals 40 261 118) (buffers 856 11))
[Message part 3 (message/rfc822, inline)]
From: Dmitry Gutov <dgutov <at> yandex.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 23223-done <at> debbugs.gnu.org Subject: Re: bug#23223: 25.0.92; Can xref-find-references be sped up? Date: Tue, 12 Apr 2016 21:49:14 +0300Version: 25.1 On 04/12/2016 06:50 PM, Eli Zaretskii wrote: > LGTM, please push. Done, and closing. > Btw, I noticed another strange thing, but I was only able to reproduce > it with the current version, before your patch: the set of results > returned by xref-find-references, when it uses IDUtils, is not > entirely repeatable. Sometimes, a few matches, sometimes a few dozen > of them, are missing. I have no idea why; the lid command > consistently returns the same number of lines each time I invoke it. That sounds troubling. Please report if you encounter this again, together with: do you get different results when immediately repeating the same search? Or do you search from different files, in different directories? Getting different results between searches from c-mode and emacs-lisp-mode is to be expected, because the latter searches in all load-path as well (and it ends up using Grep in most of those directories anyway). >semantic-symref-filepattern-alist is defined in and used by >> semantic/symref/grep.el. We can add (lisp-interaction-mode "*.el") to it. > > I think we should do that, yes. Also done (with a slightly longer value).
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.