From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Generation of tags for the current project on the fly
Date: Mon, 15 Jan 2018 21:50:33 +0300 [thread overview]
Message-ID: <98f4f0c3-6815-bf86-fa23-1a330c60b9f3@yandex.ru> (raw)
In-Reply-To: <83inc3znpu.fsf@gnu.org>
On 1/15/18 8:37 AM, Eli Zaretskii wrote:
>>> 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.
This is doable, ok.
>> 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.
It would shorten the waits, but do nothing for the CPU and disk usage.
Those I'm more worried about, actually, as a laptop user with a
not-so-great battery life on GNU/Linux.
If we just invalidate on save, the rescan doesn't happen until you
intend to use it again. And with asynchronous approach, they will occur
again and again, just as you edit and save files. With large projects,
one CPU core might always be busy this way (or does etags parallelize?
more cores then).
So maybe someone would prefer this approach, but I'd only go for it only
as a qualify-of-life improvements when scans are already pretty short.
>> 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.
Probably doesn't, indeed.
>> 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.
Thanks, so 1 second for file listing for 4.5 seconds for etags. Even if
we allowed etags to execute in parallel with find, it could only shave
it down to 4.5 seconds (and probably not even that).
>> 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.
That option is not as easy to code as what I suggested.
Further, if we just visit lisp/TAGS when in lisp/, and xref-etags-mode
is enabled, we won't be able to find the definition of 'car'.
>> 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.
You probably do it just once, though, and update very rarely. The old
way of operation is still going to work.
Can we improve the "warm" reindex times? In the first message of this
thread I mentioned GNU Global because it reportedly supports incremental
updates. Can we get such feature in etags, too?
I more or less imagine how I'd implement such a feature using Lisp and
'etags --append', but that would do nothing to help when the tags are
generated by make.
next prev parent reply other threads:[~2018-01-15 18:50 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 1:02 Generation of tags for the current project on the fly Dmitry Gutov
2018-01-12 9:01 ` Eli Zaretskii
2018-01-12 13:52 ` Dmitry Gutov
2018-01-12 18:52 ` Eli Zaretskii
2018-01-14 2:05 ` Dmitry Gutov
2018-01-14 16:21 ` Eli Zaretskii
2018-01-15 1:44 ` Dmitry Gutov
2018-01-15 5:37 ` Eli Zaretskii
2018-01-15 18:50 ` Dmitry Gutov [this message]
2018-01-16 17:50 ` Eli Zaretskii
2018-01-16 21:56 ` Dmitry Gutov
2018-01-17 15:40 ` Eli Zaretskii
2018-01-17 19:43 ` Dmitry Gutov
2018-01-17 20:12 ` Eli Zaretskii
2018-01-17 22:19 ` Dmitry Gutov
2018-01-17 22:28 ` Dmitry Gutov
2018-01-17 22:02 ` Tom Tromey
2018-01-17 22:44 ` Dmitry Gutov
2018-01-17 23:20 ` Tom Tromey
2018-01-18 0:14 ` Dmitry Gutov
2018-01-18 1:30 ` Dmitry Gutov
2018-01-19 1:21 ` Dmitry Gutov
2018-01-20 22:15 ` Tom Tromey
2018-01-20 23:57 ` Tom Tromey
2018-01-21 12:26 ` Dmitry Gutov
2018-01-30 4:45 ` Tom Tromey
2018-02-04 23:32 ` Dmitry Gutov
2018-01-30 5:05 ` Tom Tromey
2018-02-04 23:40 ` Dmitry Gutov
2018-02-05 17:06 ` Eli Zaretskii
2018-02-05 20:10 ` Dmitry Gutov
2018-02-06 19:36 ` Eli Zaretskii
2018-02-06 20:41 ` Dmitry Gutov
2018-02-07 3:26 ` Eli Zaretskii
2018-02-07 9:47 ` Dmitry Gutov
2018-02-07 21:30 ` Tom Tromey
2018-02-09 9:41 ` Dmitry Gutov
2018-02-08 20:31 ` John Yates
2018-02-09 0:22 ` Dmitry Gutov
2020-12-08 22:26 ` Dmitry Gutov
2018-01-17 11:08 ` Dmitry Gutov
2018-01-15 1:50 ` John Yates
2018-01-15 5:42 ` Eli Zaretskii
2018-01-15 15:01 ` Dmitry Gutov
2018-01-15 17:21 ` Eli Zaretskii
2018-01-15 17:45 ` Dmitry Gutov
2018-01-15 20:56 ` Matthias Meulien
2018-01-15 21:44 ` Dmitry Gutov
2018-01-15 16:33 ` John Yates
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98f4f0c3-6815-bf86-fa23-1a330c60b9f3@yandex.ru \
--to=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).