Hi Michael,

This little patch shaves 2 `process-file' invocations from both 
`vc-find-file-hook' and `vc-after-save'.

It's not fully backward-compatible (it breaks when a previously 
registered file became unregistered), but I think it's a good tradeoff.

VC doesn't handle all cases of "outside interference" anyway: for 
example, the cached return value of `vc-working-revision' is invalidated 
only after the file is checked in, moved, or deleted, not after each 
save, and switching to another branch in Git is a much more common 
occurrence.

A more complex solution, though also applicable to vc-hg, would be to 
move most of the code from `vc-git-registered' to `vc-git-state', then 
modify `vc-git-registered' and `vc-hg-registered' to call `vc-state' 
(for caching) and then interpret its return value (what 
`vc-hg-registered' already does). Since `vc-registered' calls 
`vc-xx-registered' functions when selecting the backend, we'd also need 
to clear the cached 'vc-state value after each call with negative result.

This would mean +1 `process-file' invocation with Git in 
`vc-after-save', compared to the attached patch, but -1 with Hg in 
`vc-find-file-hook'.

On 26.06.2012 16:14, Michael Albinus wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> After setting vc-git-program explicitly to "C:/Program Files
>> (x86)/Git/bin/git.exe" (by default, it was calling "C:/Program Files
>> (x86)/Git/cmd/git.CMD"), the average time of git command calls went
>> down from 0.2s to 0.03s, so the problem with Git is about 7 times less
>> important now.
>
> If the git repository is remote (accessed via Tramp), this is still a
> serious issue. I'm plagued by this every single day. Less `process-file'
> invocations would be more than welcome. Maybe vc-git can cache some results?
>
>> -- Dmitry
>
> Best regards, Michael.
>
>