GNU bug report logs -
#1741
23.0.60; vc fail to register file while logged as /su:: with tramp
Previous Next
Full log
View this message in rfc822 format
>> 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
This bug report was last modified 16 years and 101 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.