[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: 23223@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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
impressive.
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.
- bug#23223: 25.0.92; Can xref-find-references be sped up?, (continued)
bug#23223: 25.0.92; Can xref-find-references be sped up?, Eli Zaretskii, 2016/04/06
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Dmitry Gutov, 2016/04/06
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Eli Zaretskii, 2016/04/07
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Dmitry Gutov, 2016/04/08
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Eli Zaretskii, 2016/04/09
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Dmitry Gutov, 2016/04/10
- bug#23223: 25.0.92; Can xref-find-references be sped up?,
Eli Zaretskii <=
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Dmitry Gutov, 2016/04/11
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Eli Zaretskii, 2016/04/12
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Dmitry Gutov, 2016/04/12
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Eli Zaretskii, 2016/04/12
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Dmitry Gutov, 2016/04/12
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Eli Zaretskii, 2016/04/12
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Dmitry Gutov, 2016/04/13
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Eli Zaretskii, 2016/04/13
- bug#23223: 25.0.92; Can xref-find-references be sped up?, Eli Zaretskii, 2016/04/15