From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Generation of tags for the current project on the fly Date: Mon, 15 Jan 2018 07:37:49 +0200 Message-ID: <83inc3znpu.fsf@gnu.org> References: <4559858d-eb32-d071-fdad-e51430700260@yandex.ru> <83shbb30z1.fsf@gnu.org> <8360863o6a.fsf@gnu.org> <27a58fb2-d2ee-e5fc-158d-ec41be401987@yandex.ru> <83y3l0za1f.fsf@gnu.org> <259c557d-e3a3-c01b-9ba3-30df09d247ea@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1515994586 8299 195.159.176.226 (15 Jan 2018 05:36:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 05:36:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 15 06:36:22 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eaxRL-0001Ak-2w for ged-emacs-devel@m.gmane.org; Mon, 15 Jan 2018 06:36:11 +0100 Original-Received: from localhost ([::1]:38390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eaxTL-0003O4-3X for ged-emacs-devel@m.gmane.org; Mon, 15 Jan 2018 00:38:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eaxTD-0003Nb-8F for emacs-devel@gnu.org; Mon, 15 Jan 2018 00:38:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eaxTA-0005Sl-5F for emacs-devel@gnu.org; Mon, 15 Jan 2018 00:38:07 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eaxTA-0005Sh-1d; Mon, 15 Jan 2018 00:38:04 -0500 Original-Received: from [176.228.60.248] (port=3441 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eaxT9-00073g-Df; Mon, 15 Jan 2018 00:38:03 -0500 In-reply-to: <259c557d-e3a3-c01b-9ba3-30df09d247ea@yandex.ru> (message from Dmitry Gutov on Mon, 15 Jan 2018 04:44:58 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:221961 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Mon, 15 Jan 2018 04:44:58 +0300 > > On 1/14/18 7:21 PM, Eli Zaretskii wrote: > > >> OK, so if the user says yes, we "temporarily visit" to auto-generated > >> tags table. Then the user saves a file and that table get invalidated > >> (or via some other mechanism), and we want to index it again. Ask again? > > > > No, I think asking once per project should be enough. > > Until the end of the current Emacs session? And ask again after restart? Yes. > What about if the user switches to a different project and then back? Ideally, don't ask anymore about that project. > > I mean the first time the tags table is required might very well be at > > the beginning of working on a project, at which time the project > > source tree is not yet in the cache. > > Yes, and? The user will need it to be indexed either way, right? Yes, but my point was that col-cache times cannot be ignored. > There's also another optimization opportunity: performing reindexing in > an asynchronous fashion, in the background (maybe after a timeout, too), > after any file is changed and saved. This one comes with its own > tradeoffs, though. Doing that asynchronously could be an automatic action , not in need of any user confirmation. It complicates the implementation a bit, but perhaps not too much, so this could be a good design choice. > To measure the full time: > > (benchmark 1 '(progn (etags--project-tags-cleanup) > (etags--maybe-use-project-tags))) 5.5 sec with warm cache. This is with an unoptimized Emacs, btw, but most of the time is spent by external programs, so perhaps this doesn't matter. > To measure the time to generate the list of files only: > > (benchmark 1 '(all-completions "" (project-file-completion-table > (project-current) (list default-directory)))) 0.95 sec with cold cache, 0.23 with warm cache. > >> 'git ls-files' will probably be faster still. > > > > Yes, but that only works in Git repositories. > > We can probably optimize for that use case these days. Git or some other > VCS is usually in place, especially in non-toy projects. For the projects using Git, yes. > How do we figure which files to visit? Do we just visit src/TAGS and > expect the rest to be 'include'-d. I think just visit TAGS in the directory of the source whose symbol is requested, or maybe use locate-dominating-file to look higher in the tree if not found in the current directory. > Here's another one: considering the reindexing costs are not always > negligible and depend on the size of a project, will there be actual > benefit to using the proposed scheme in GNU projects like Emacs, GCC and > others (those are the ones that use 'make TAGS')? Or is there a subset > of them, at least, which we expect to benefit? That's a good question. But if the tags table is automatically produced in the background, the time this takes is much less important, and having TAGS always up to date would be a valuable feature. FWIW, I do "make TAGS" in every large project I start working on seriously, so at least for me this is important.