[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23223: 25.0.92; Can xref-find-references be sped up?

From: Eli Zaretskii
Subject: bug#23223: 25.0.92; Can xref-find-references be sped up?
Date: Mon, 11 Apr 2016 18:56:54 +0300

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Mon, 11 Apr 2016 02:27:34 +0300
> Please try the attached patch. It cuts the time to search for 
> 'current_buffer' from 4.5s to 0.75s here.

Thanks, I see a similar speedup (from 13 sec to just 3).  Very

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, because the new code finds this:

 122:    (buf == current_buffer ? BEGV                  \

but not this:

  42: #define BEGV (current_buffer->begv)

IOW, if the symbol is followed by a "->", it is not recognized.

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.
Curiously, this doesn't happen when there's an ID file and IDutils is
invoked.  Is this expected?

> > E.g., the "M-x gid" command, which comes
> > with IDutils and is a trivial wrapper around lid invocation, simply
> > shows the output in a Grep-like buffer, through which you can step
> > with next-error.
> Do you actually want xref-find-regexp, and not xref-find-references?

No, of course not. "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.  And that is what I want: symbol hits, not just
regular expressions that ignore the source language syntax.1

> > It is lightning-fast: what takes 13 sec with
> > xref-find-references, takes less than 2 sec with "M-x gid".
> 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.

> 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?

> 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?

Thanks again for working on this.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]