From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23223: 25.0.92; Can xref-find-references be sped up? Date: Mon, 11 Apr 2016 18:56:54 +0300 Message-ID: <83zit0f8ah.fsf@gnu.org> References: <83pou4m6h7.fsf@gnu.org> <902ac022-3a76-c363-0c77-12b1cdb8d521@yandex.ru> <8360vumzk4.fsf@gnu.org> <83mvp5lauu.fsf@gnu.org> <4424e043-31c7-0da4-213a-ee8ac31d9265@yandex.ru> <83vb3ri6q0.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1460390305 3335 80.91.229.3 (11 Apr 2016 15:58:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Apr 2016 15:58:25 +0000 (UTC) Cc: 23223@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 11 17:58:14 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1apeE9-0003j0-9X for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Apr 2016 17:58:13 +0200 Original-Received: from localhost ([::1]:57651 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apeE8-0006P6-QN for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Apr 2016 11:58:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apeE2-0006G6-Nc for bug-gnu-emacs@gnu.org; Mon, 11 Apr 2016 11:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apeDy-00019A-Mj for bug-gnu-emacs@gnu.org; Mon, 11 Apr 2016 11:58:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apeDy-000196-JJ for bug-gnu-emacs@gnu.org; Mon, 11 Apr 2016 11:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1apeDy-0001Vm-By for bug-gnu-emacs@gnu.org; Mon, 11 Apr 2016 11:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Apr 2016 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23223 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23223-submit@debbugs.gnu.org id=B23223.14603902605776 (code B ref 23223); Mon, 11 Apr 2016 15:58:02 +0000 Original-Received: (at 23223) by debbugs.gnu.org; 11 Apr 2016 15:57:40 +0000 Original-Received: from localhost ([127.0.0.1]:59625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apeDc-0001V6-Hj for submit@debbugs.gnu.org; Mon, 11 Apr 2016 11:57:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apeDa-0001Us-3z for 23223@debbugs.gnu.org; Mon, 11 Apr 2016 11:57:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apeDR-0000yn-4r for 23223@debbugs.gnu.org; Mon, 11 Apr 2016 11:57:33 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apeDR-0000yj-1Q; Mon, 11 Apr 2016 11:57:29 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1030 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1apeDN-00041h-Tc; Mon, 11 Apr 2016 11:57:28 -0400 In-reply-to: (message from Dmitry Gutov on Mon, 11 Apr 2016 02:27:34 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:116382 Archived-At: > Cc: 23223@debbugs.gnu.org > From: Dmitry Gutov > 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.