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

[Stefan Monnier]

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