unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Glenn Morris <rgm@gnu.org>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, sds@gnu.org, 42966@debbugs.gnu.org
Subject: bug#42966: 28.0.50; vc-dir: wrong backend
Date: Tue, 27 Oct 2020 00:11:07 +0200	[thread overview]
Message-ID: <29720047-f8e3-e2aa-076c-2743a46c0925@yandex.ru> (raw)
In-Reply-To: <vrblgor6us.fsf@fencepost.gnu.org>

On 26.10.2020 23:54, Glenn Morris wrote:
> Dmitry Gutov wrote:
> 
>>> That makes sense, but it's just a performance hack, isn't it?  The
>>> result should be the same as the less invasive "loop over all the
>>> backends and collect the most specific one".
>>
>> Pretty much. Except it should naturally limit the traversal up the
>> directory tree, so it feels like a good architecture, not just a
>> "hack".
> 
> Indeed, it just seems like the Right Thing to Do, not a hack.
> Not having been paying attention, I was surprised to see the adopted solution
> goes for "loop over every VC backend, and every directory up the tree,
> then filter the results", rather than "walk up the directory tree,
> stopping when a backend claims responsibility".

I didn't want to insist on it because upon some thinking it seemed to me 
that the remote case might be the only problematic one. And 
one-traversal-per-backend might be more optimizable by Tramp (e.g. via a 
mini-program) than one-check-per-directory-level. But perhaps the latter 
could be optimized using a file handler or an advice just as well.

> I would think efficiency matters in such a frequent operation.
> As a (completely unscientific) data point, my first single core
> bootstrap build after this change took about 5% longer than before
> (22m5s v 21m4s). But of course a single measurement means nothing.

Was that with a rotating disk?

A few more experiments should help, to establish whether that was a 
fluke or not.





      parent reply	other threads:[~2020-10-26 22:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21 15:15 bug#42966: 28.0.50; vc-dir: wrong backend Sam Steingold
2020-10-16  8:55 ` Lars Ingebrigtsen
2020-10-16 12:44   ` Dmitry Gutov
2020-10-16 14:41     ` Lars Ingebrigtsen
2020-10-16 14:44       ` Dmitry Gutov
2020-10-17  7:02         ` Lars Ingebrigtsen
2020-10-17  7:13         ` Lars Ingebrigtsen
2020-10-17  7:19           ` Lars Ingebrigtsen
2020-10-17 20:41             ` Dmitry Gutov
2020-10-18  8:26               ` Lars Ingebrigtsen
2020-10-17 20:44           ` Dmitry Gutov
2020-10-18  7:38             ` Michael Albinus
2020-10-23 23:53               ` Dmitry Gutov
2020-10-24 13:41                 ` Michael Albinus
2020-10-24 19:42                   ` Dmitry Gutov
2020-10-25 17:49                     ` Michael Albinus
2020-10-26 14:29                       ` Dmitry Gutov
2020-10-26 15:17                         ` Michael Albinus
2020-10-26 20:12                           ` bug#42966: (no subject) Lars Ingebrigtsen
2020-10-26 20:13                           ` Lars Ingebrigtsen
2020-10-26 20:55                             ` bug#42966: Dmitry Gutov
2020-10-26 21:02                               ` bug#42966: Lars Ingebrigtsen
2020-10-26 21:44                                 ` bug#42966: Dmitry Gutov
2020-10-26 21:11                           ` bug#42966: 28.0.50; vc-dir: wrong backend Dmitry Gutov
2020-10-18  8:32             ` Lars Ingebrigtsen
2020-10-16 15:35 ` Glenn Morris
2020-10-16 18:19   ` Dmitry Gutov
2020-10-17  6:06     ` Lars Ingebrigtsen
2020-10-17 20:01       ` Dmitry Gutov
2020-10-18  8:31         ` Lars Ingebrigtsen
2020-10-26 21:54         ` Glenn Morris
2020-10-26 21:58           ` Lars Ingebrigtsen
2020-10-26 22:14             ` Dmitry Gutov
2020-10-26 22:11           ` Dmitry Gutov [this message]

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=29720047-f8e3-e2aa-076c-2743a46c0925@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=42966@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=rgm@gnu.org \
    --cc=sds@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).