GNU bug report logs - #23223
25.0.92; Can xref-find-references be sped up?

Previous Next

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.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23223 <at> debbugs.gnu.org
Subject: bug#23223: 25.0.92; Can xref-find-references be sped up?
Date: Tue, 12 Apr 2016 02:25:54 +0300
[Message part 1 (text/plain, inline)]
On 04/11/2016 06:56 PM, Eli Zaretskii wrote:

> Unfortunately, it seems to miss matches: out of 1127 matches of
> current_buffer with the original version, the new one only shows 963.
> It sounds like some conditions on what exactly is a symbol need
> adjustment,

Ooh, that's a great catch, thanks! Turns out, auto-mode-alist wasn't 
getting applied because buffer-file-name wasn't set. Fixing that added 
~25% performance hit, so I also added xref--find-buffer-visiting to 
cache the expensive lookup mentioned previously. See the new patch attached.

That seems to about exhaust the optimization opportunity here.

> As an aside, if I invoke xref-find-references without an ID file,
> which AFAIU means Emacs will invoke find+grep, I get this error:
>
>   semantic-symref-derive-find-filepatterns: Customize ‘semantic-symref-filepattern-alist’ for lisp-interaction-mode
>
> unless I invoke xref-find-references from a buffer in C mode.

...or the current major mode is one of the currently supported ones, via 
the above variable.

> Curiously, this doesn't happen when there's an ID file and IDutils is
> invoked.  Is this expected?

Yes. semantic-symref-filepattern-alist is defined in and used by 
semantic/symref/grep.el. We can add (lisp-interaction-mode "*.el") to it.

> "gid" is just a short for "lid -R grep", so the
> contents I get is the same as xref-find-references does, it's just
> formatted differently.

Not exactly: you get more false positives because it doesn't apply the 
language-aware filtering.

>> What's the new time you get from the former?
>
> 3 sec (in an unoptimized build, I'd expect this to become 1 sec in an
> optimized build).  So we are OK speed-wise, we just need to fix the
> misses mentioned above.

Cool.

>> By the way, the "insert-file-contents + set-auto-mode" dance comes with
>> a new minor downside: extra chatter from the major modes. E.g. try
>> project-file-regexp with "should have received a copy".
>
> I don't see this in xref-find-references.  Should I?

Not at all. xref-find-references only searches in the files related to 
the current one by type (or in a predefined database like id-utils's one).

The chatter I got was from e.g. sh-mode (about the indentation variable 
being guessed), nxml-mode, and so on, with matches in ~4000 files.

>> We can avoid saving it to the message log, but it appears in the
>> echo area either way.
>
> Can't you bind inhibit-message to a non-nil value?

That works!

> Thanks again for working on this.

Thanks for the thoughtful bug report.
[xref-with-temp-buffer.diff (text/x-patch, attachment)]

This bug report was last modified 9 years and 93 days ago.

Previous Next


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