[Top][All Lists]

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

bug#11757: Fwd: bug#11757: Acknowledgement (24.1.50; vc-git calls `proce

From: Michael Albinus
Subject: bug#11757: Fwd: bug#11757: Acknowledgement (24.1.50; vc-git calls `process-file' too many times)
Date: Wed, 18 Jul 2012 16:11:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Forwarded to debbugs, for the archives.

--- Begin Message --- Subject: Re: Fwd: Re: bug#11757: Acknowledgement (24.1.50; vc-git calls `process-file' too many times) Date: Wed, 18 Jul 2012 08:07:46 +0400 User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
On 17.07.2012 11:20, Michael Albinus wrote:
(*): There seems to be at least one `call-process' call in vc-git.el,
which I regard as an error. Maybe you could correct this in your patch,

Added to the patch, as well as the ChangeLog entries.

I haven't prepared test cases yet. The basic idea is to have a (test)
file under git, and to apply some default scenarios with it. Not just
open, edit, save, commit (that might be the most simple scenario), but
something which reflects the usual workflow better. Escpecially,

The above is my usual workflow, actually, when repeated several times.

keeping the file opened in an Emacs buffer, during several workflow
cycles - this would give cached values the possibility to show their
power (or not).

Since I have a clear picture in my mind why this wouldn't make a difference (for one, there's no time-based expiration), I'm having a hard time choosing a meaningful longer scenario.

So I'm just doing one scenario now. If you write a different one, I can do that next.

1. git init test (outside of Emacs)
2. find-file in this directory (creating the new file)
3. edit, save, `vc-next-action' (registering the new file)
4. repeat step 3 (makes first commit)
5. repeat step 4 (makes second commit)
6. `vc-rename-file'
7. `vc-next-action' (commit)
8. `vc-delete-file'

(This automatically closes the buffer and leaves the repo with 2 files removed from the disk and staged for deletion.)

As we both agree, calling processes is the most time consuming
action. We might concentrate on counting the number of process calls,
the other Lisp-based actions are negligible. I would trace all vc-*
function calls, and `process-file' (*), like this:

(require 'trace)
(dolist (elt (all-completions "vc-" obarray 'functionp))
   (trace-function-background (intern elt)))
(trace-function-background 'process-file)

This returns also two different trace buffers, which could be compared
by ediff easily, in order to see how vc behaves.

Done this twice, logs 1 and 3 - without the patch, 2 and 4 - with the patch. 1 ~ 3 and 2 ~ 4, so you may just as well compare only one pair.

The difference: a few getprop/setprop calls, and one full uncached `vc-git-registered' call in `vc-register' (after "git add" was called), all in favor of the patched version (which doesn't make the above calls). The last one is interesting, because it shows that `vc-register' doesn't require `vc-git-registered' to return `t' before it assigns Git backend to the buffer. So at the same point where the unpatched code calls `vc-git-registered' and it finally returns true, the patched code just assumes it's true, and doesn't call the function. :) A bit risky, but not wrong, at least in this case.

This would have been different if the file existed and was registered in the repository before step 2, then the first call to `vc-git-registered' would have returned `t' in both versions.

P.S. `ediff' says there are no differences after around 43% mark, but there are. For example, line 1021 in trace-3.log shows a call to `vc-git-registered', whereas the respective line 979 in trace-4.log shows that the call is skipped. Same with `diff' in the console, it ignores these changes, no idea why. Maybe I just fail at diffing.


Attachment: vc-git.diff
Description: Text document

Attachment: trace-1.log
Description: Text document

Attachment: trace-2.log
Description: Text document

Attachment: trace-3.log
Description: Text document

Attachment: trace-4.log
Description: Text document

--- End Message ---

reply via email to

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