From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#42966: 28.0.50; vc-dir: wrong backend Date: Tue, 27 Oct 2020 00:11:07 +0200 Message-ID: <29720047-f8e3-e2aa-076c-2743a46c0925@yandex.ru> References: <54k0vq420i.fsf@fencepost.gnu.org> <87pn5h1j4b.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19824"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: Lars Ingebrigtsen , sds@gnu.org, 42966@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 26 23:19:41 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXAq5-00052z-CN for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Oct 2020 23:19:41 +0100 Original-Received: from localhost ([::1]:54100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXAq4-0000LX-DG for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Oct 2020 18:19:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41240) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXAih-0007jo-9i for bug-gnu-emacs@gnu.org; Mon, 26 Oct 2020 18:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58510) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXAig-0006cm-1K for bug-gnu-emacs@gnu.org; Mon, 26 Oct 2020 18:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kXAif-00082o-QZ for bug-gnu-emacs@gnu.org; Mon, 26 Oct 2020 18:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Oct 2020 22:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42966 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 42966-submit@debbugs.gnu.org id=B42966.160375027830865 (code B ref 42966); Mon, 26 Oct 2020 22:12:01 +0000 Original-Received: (at 42966) by debbugs.gnu.org; 26 Oct 2020 22:11:18 +0000 Original-Received: from localhost ([127.0.0.1]:41823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXAhy-00081l-11 for submit@debbugs.gnu.org; Mon, 26 Oct 2020 18:11:18 -0400 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:42190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXAhw-00081V-Ib for 42966@debbugs.gnu.org; Mon, 26 Oct 2020 18:11:16 -0400 Original-Received: by mail-ed1-f49.google.com with SMTP id v19so11305224edx.9 for <42966@debbugs.gnu.org>; Mon, 26 Oct 2020 15:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W8TpQA6DA5mqc9CrfDEPpT1P+dgWzQcQf5N/VRzdjs4=; b=SzowyJ6qSS3ookf8JsnzIph4nzykIJgqEJ7JIBvnYiXr3WT5dyyPRGF54OsryATJCC 3SojDuIJlr6eotVaD7Any4jpIM0+7vEWZoxXOZFlHYTrQ8/PCw9TZ05JFKm2AlSdMN9p AuuNGMfhgrJLumTOj06Z7D+BWpTEqAMrvCcRkvLYJ4+6dQyuOsOWCdf9pIm8NvNgJZD1 zqqbWrssw/9qUQ5vDVBs7oKYYr5A6dlKtMZZwc4QR8MyUKsuR1ZTeX3Wq1dhZbQkkNK9 L+bYzHMQzm9FnqtjwcJvgdL6SVdZEe5fUk6L4qzAlXEoyt7XI8s2tUbNqoPRzqCdLDFL H1xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=W8TpQA6DA5mqc9CrfDEPpT1P+dgWzQcQf5N/VRzdjs4=; b=DkAOQ0MJDjVWqDsRZH+o2PTgAy+rHM+OtKKoRNFt/qjpy0YkWpo+S/taMY25KCwk2f zskrMkKATw7UT6aB4CwwiM14MJ3SDpAj4+OhNY5PortM0ArBZCRBfzGVGIDLEbfDd1bE xhRahbJbdJ5yUDAl6CMohIE2uFwGdqwY04rb1cSAjMS4O3TRMHfy4xHavrBQDNmWqcOW SNj2sXiOIc/D9ZIudDvGuZJLIERUZZFeWmQpF/uiKVC9TRX42g/rbJ7SVWbdXbfUoQ9f F9ESoyAEsTTeKVmRB8wA/NJOv4NN0tRMPpvEzw6Rq3aipwlsSyQJRJlGMB19RNk2JPb9 dWrQ== X-Gm-Message-State: AOAM532Ws/96qsFhSJ5cmEoS2bs12IIQ20G6xyV3msc7P8srP39b/yIN CbCEtxeAoS//DeR2FZknvsaPjaltLluaMw== X-Google-Smtp-Source: ABdhPJzMEnpmE+Vm49UwrFNkkwOeCT0abMR9q8ZdsdULG764iQfVFMs2tiFajPitKGRluvYuUXUF3Q== X-Received: by 2002:aa7:d658:: with SMTP id v24mr14670802edr.327.1603750270224; Mon, 26 Oct 2020 15:11:10 -0700 (PDT) Original-Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id i14sm6538393ejp.2.2020.10.26.15.11.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 15:11:09 -0700 (PDT) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191681 Archived-At: 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.