From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jonathan H Newsgroups: gmane.emacs.bugs Subject: bug#21383: Static revisions in vc-working-revision Date: Thu, 3 Sep 2015 10:34:08 -0700 Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> <55E84382.3030209@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113fd722819dde051edb324a X-Trace: ger.gmane.org 1441301723 16216 80.91.229.3 (3 Sep 2015 17:35:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Sep 2015 17:35:23 +0000 (UTC) Cc: 21383-done@debbugs.gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 03 19:35:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ZXYPo-0008HZ-GC for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Sep 2015 19:35:12 +0200 Original-Received: from localhost ([::1]:50642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXYPn-0006VB-JL for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Sep 2015 13:35:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXYPj-0006Sr-HO for bug-gnu-emacs@gnu.org; Thu, 03 Sep 2015 13:35:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXYPe-0003Zm-M4 for bug-gnu-emacs@gnu.org; Thu, 03 Sep 2015 13:35:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXYPe-0003Ym-Jc for bug-gnu-emacs@gnu.org; Thu, 03 Sep 2015 13:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZXYPe-0007yb-97 for bug-gnu-emacs@gnu.org; Thu, 03 Sep 2015 13:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jonathan H Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Sep 2015 17:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21383-done@debbugs.gnu.org id=D21383.144130168030628 (code D ref 21383); Thu, 03 Sep 2015 17:35:02 +0000 Original-Received: (at 21383-done) by debbugs.gnu.org; 3 Sep 2015 17:34:40 +0000 Original-Received: from localhost ([127.0.0.1]:47863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXYPI-0007xv-Dg for submit@debbugs.gnu.org; Thu, 03 Sep 2015 13:34:40 -0400 Original-Received: from mail-io0-f176.google.com ([209.85.223.176]:33618) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXYPG-0007xn-AK for 21383-done@debbugs.gnu.org; Thu, 03 Sep 2015 13:34:38 -0400 Original-Received: by iofh134 with SMTP id h134so66899022iof.0 for <21383-done@debbugs.gnu.org>; Thu, 03 Sep 2015 10:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3idjm+gcxG22fXhcakc4dX6KJkYvxBWAfGb4E/KGDj0=; b=LjSvINIf8MM6AJMBVnejwOL0Z+ShKwX6R3EpKVofMgIkvtCo6QA1+ZY8chsiRGKwVk qrALf71IQIxG/IL93MkxYzW+Hs5Z/NY+5PglWePpFl4LPcRyT9Lgu2rBrylsTiwGWV/7 CS2iHr1P1vRNHU0tazSA745TMqPrO1FK9117sdVZaTKUHWEi8/gblMEz8apxXije3ArY hqSDHvsZpboYNK1UXfBJ+xaqlMuvT2h69G9ZiTn4X1EH1FzPWoenQFqH7lvbEh9tv/nW HZfcecMdy4Df7rak4hq3IGEB5SjpbQhoC3J4ffN+q2FBuBr4gZdboZr3h4OlmwgBh8oZ xjGA== X-Received: by 10.107.13.3 with SMTP id 3mr493364ion.70.1441301677574; Thu, 03 Sep 2015 10:34:37 -0700 (PDT) Original-Received: by 10.79.110.197 with HTTP; Thu, 3 Sep 2015 10:34:08 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106116 Archived-At: --001a113fd722819dde051edb324a Content-Type: text/plain; charset=UTF-8 > Indeed, mode-line updates are *very* frequent (more than once per > command), so we really want to avoid running processes at that point. I though the new implementation of the vc-git mode line doesn't use vc-working-revision, so in this specific case, making vc-working-revision slower won't hurt us there. > I wonder if that's true. Caching in a property is obviously fast, and process calls are necessarily an order of magnitude slower (and slower still on certain platforms). True, but you have to check that the cache is invalid somehow. If you want to be super correct, a rev-parse is probably the fastest way. I suppose it would be pretty fast to check the mtime of the .git directory inside emacs and invalidate that when it changes. Although filesystem timestamps usually make me nervous, it's probably okay in this instance? On Thu, Sep 3, 2015 at 9:17 AM, Stefan Monnier wrote: > > Maybe you should write a patch and test it on Windows (or have someone > else > > do it), and see whether the mode-line updates don't become > > perceptibly slower. > > Indeed, mode-line updates are *very* frequent (more than once per > command), so we really want to avoid running processes at that point. > > > Stefan > --001a113fd722819dde051edb324a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Indeed, mode-line updates are *very* f= requent (more than once per
> command), so we really want to avoid running processes at that point.<= br>
I though the new implementation of the vc-git mode line doesn&= #39;t use vc-working-revision, so in this specific case, making vc-working-= revision slower won't hurt us there.

> I wonder if that's= true. Caching in a property is obviously fast, and=20 process calls are
necessarily an order of magnitude slower (and slower= =20 still on certain platforms).

True, but you have to check that = the cache is invalid somehow. If you want to be super correct, a rev-parse = is probably the fastest way. I suppose it would be pretty fast to check the= mtime of the .git directory inside emacs and invalidate that when it chang= es. Although filesystem timestamps usually make me nervous, it's probab= ly okay in this instance?



On Th= u, Sep 3, 2015 at 9:17 AM, Stefan Monnier <monnier@iro.umontreal.ca= > wrote:
&= gt; Maybe you should write a patch and test it on Windows (or have someone = else
> do it), and see whether the mode-line updates don't become
> perceptibly slower.

Indeed, mode-line updates are *very* frequent (more than once per command), so we really want to avoid running processes at that point.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--001a113fd722819dde051edb324a--