all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 23223@debbugs.gnu.org
Subject: bug#23223: 25.0.92; Can xref-find-references be sped up?
Date: Mon, 11 Apr 2016 18:56:54 +0300	[thread overview]
Message-ID: <83zit0f8ah.fsf@gnu.org> (raw)
In-Reply-To: <d924d9d8-c7c4-3632-a7fc-9430d6ccd130@yandex.ru> (message from Dmitry Gutov on Mon, 11 Apr 2016 02:27:34 +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.





  reply	other threads:[~2016-04-11 15:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 15:16 bug#23223: 25.0.92; Can xref-find-references be sped up? Eli Zaretskii
2016-04-06  0:37 ` Dmitry Gutov
2016-04-06 15:09   ` Dmitry Gutov
2016-04-06 17:20     ` Eli Zaretskii
2016-04-06 23:11       ` Dmitry Gutov
2016-04-07  2:49         ` Eli Zaretskii
2016-04-06 17:12   ` Eli Zaretskii
2016-04-07  0:11     ` Dmitry Gutov
2016-04-07 15:03       ` Eli Zaretskii
2016-04-09  3:12         ` Dmitry Gutov
2016-04-09  7:25           ` Eli Zaretskii
2016-04-10 23:27             ` Dmitry Gutov
2016-04-11 15:56               ` Eli Zaretskii [this message]
2016-04-11 23:25                 ` Dmitry Gutov
2016-04-12 15:50                   ` Eli Zaretskii
2016-04-12 18:49                     ` Dmitry Gutov
2016-04-12 19:16                       ` Eli Zaretskii
2016-04-12 20:26                         ` Dmitry Gutov
2016-04-13  2:44                           ` Eli Zaretskii
2016-04-13 10:18                             ` Dmitry Gutov
2016-04-13 15:16                               ` Eli Zaretskii
2016-04-15 14:29                                 ` Eli Zaretskii

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zit0f8ah.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=23223@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.