From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: etags completion table (was: bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files) Date: Fri, 29 May 2015 17:41:38 -0400 Message-ID: References: <555EC552.5010600@swipnet.se> <837frvywfn.fsf@gnu.org> <55650812.60909@yandex.ru> <831ti2yu1a.fsf@gnu.org> <5565E28A.5040507@yandex.ru> <83wpzuxbtd.fsf@gnu.org> <5565E8AB.5020107@yandex.ru> <83r3q2xa3q.fsf@gnu.org> <5566583F.7020503@yandex.ru> <83h9qxxvo4.fsf@gnu.org> <5566EC49.8010907@yandex.ru> <837frsycly.fsf@gnu.org> <5567351E.7020006@yandex.ru> <83zj4owthp.fsf@gnu.org> <5567AE52.1000600@yandex.ru> <83fv6fx0nk.fsf@gnu.org> <55687241.5030200@yandex.ru> <55689E02.5040605@yandex.ru> <5568CD36.2030703@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1432935733 5886 80.91.229.3 (29 May 2015 21:42:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 May 2015 21:42:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 29 23:42:03 2015 Return-path: Envelope-to: ged-emacs-devel@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 1YyS2U-0005ol-KO for ged-emacs-devel@m.gmane.org; Fri, 29 May 2015 23:42:02 +0200 Original-Received: from localhost ([::1]:37802 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyS2T-0001VA-L8 for ged-emacs-devel@m.gmane.org; Fri, 29 May 2015 17:42:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyS2B-0001Ow-6Y for emacs-devel@gnu.org; Fri, 29 May 2015 17:41:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YyS28-0003YI-0Y for emacs-devel@gnu.org; Fri, 29 May 2015 17:41:43 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyS27-0003Wk-TA for emacs-devel@gnu.org; Fri, 29 May 2015 17:41:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C0CwA731xV/3K9xEVcgxBUXoJQwQwJgVqFcQQCAoE8ORQBAQEBAQEBgQpBBYNdAQEDAVYWCgMQGSYHCxQYDSSINwgNzxYBAQEBBgEBAQEejHcBg0cHhC0FlyGINJNqgUUjYYEFJA0PFYFZIjEBgkYBAQE X-IPAS-Result: A0C0CwA731xV/3K9xEVcgxBUXoJQwQwJgVqFcQQCAoE8ORQBAQEBAQEBgQpBBYNdAQEDAVYWCgMQGSYHCxQYDSSINwgNzxYBAQEBBgEBAQEejHcBg0cHhC0FlyGINJNqgUUjYYEFJA0PFYFZIjEBgkYBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="123151018" Original-Received: from 69-196-189-114.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.196.189.114]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2015 17:41:37 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 302D8AE0BA; Fri, 29 May 2015 17:41:38 -0400 (EDT) In-Reply-To: <5568CD36.2030703@yandex.ru> (Dmitry Gutov's message of "Fri, 29 May 2015 23:33:58 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186945 Archived-At: >> Oh, then it's a non-starter (unless the search can be sped up). > I've posted the numbers along with the two versions of the patch: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20629#101 > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20629#107 Hmm... I missed those, sorry. I see the first patch says that it takes 1.34s to build the obarray and 0.78s to build an equivalent list of strings, so we could change the code so as to keep the completion table as a pre-built list of strings instead of a pre-built obarray. It will also save us a bit of memory. As for doing the search each time, the possible gain on the first completion (0.3s instead of 0.78s) doesn't make up for the loss of going from 0.02s to 0.3s on subsequent completions. So that seems like a non-starter, unless we can speed it up significantly. It shouldn't be too hard to keep the worst case at 0.76s, but lowering the 0.3s seems harder. Obviously we could get rid of the "looking-at" within the loop (fold it into the preceding re-search-forward), but it seems unlikely that this would gain us much when there are few matches. Stefan