[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1741: 23.0.60; vc fail to register file while logged as /su:: with t

From: Stefan Monnier
Subject: 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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]