GNU bug report logs - #1741
23.0.60; vc fail to register file while logged as /su:: with tramp

Previous Next

Full log

Message #63 received at 1741 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 1741 <at> debbugs.gnu.org
Subject: Re: bug#1741: 23.0.60; vc fail to register file while logged as /su:: with tramp
Date: Sun, 12 Apr 2009 18:51:17 -0400

>> process-file is something that it not used very often, so I think it's
>> perfectly OK to flush the whole host's cache at that point.  If it turns
>> out to be a performance problem, we can refine this choice.

> It depends on the use case. `find-grep-dired' is something I call
> permanently, for example.

Sure.  But think of how many Tramp operations take place between those
calls to process-file and what proportion of those operations will be
affected by the cache-flush:
- X% will not be affected because it wasn't in the cache.
- Y% will be affected.
- the remaining (100-X-Y)% won't be affected because it touches the same
  data as the previous Y%.
My guess is that Y is sufficiently low (e.g. compared to X) for it not
to be a problem.

> For a performance comparision, you could check the figures in
> <http://cvs.savannah.gnu.org/viewvc/*checkout*/tramp/test/tramp-time.el?root=tramp>.

> Tramp 2.0 has no cache, Tramp 2.1 does.  The figures are some years old,
> but they shall be still valid.

This only measures the effectiveness of caching on synthetic benchmarks.
I do not doubt that the cache is effective.  Flushing will obviously
have an effect on performance, but that doesn't mean that flushing the
cache during process-file will cause a performance problem.

AFAIK the main benefit of the cache is to bundle up all the redundant
`file-attibutes' calls that take place during something like
`find-file-noselect'.  Such optimizations won't be affected by the
cache-flush.  So I expect that the cache-flush I suggest won't cause
a performance problem.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.