Commit performance, or lack thereof

Starting in the kernel tree, if one edits and adds a single file and then commits it w/o specifying the file name as an argument to commit, git uses 10 or so Megs of VM and one sees performace akin to this:

,----« gtime -v git commit -m 'make oldconfig' »
| [master 53d6af1] make oldconfig
|  1 files changed, 5 insertions(+), 2 deletions(-)
| 	Command being timed: "git commit -m make oldconfig"
| 	User time (seconds): 0.26
| 	System time (seconds): 1.06
| 	Percent of CPU this job got: 2%
| 	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:47.04
| 	Average shared text size (kbytes): 0
| 	Average unshared data size (kbytes): 0
| 	Average stack size (kbytes): 0
| 	Average total size (kbytes): 0
| 	Maximum resident set size (kbytes): 0
| 	Average resident set size (kbytes): 0
| 	Major (requiring I/O) page faults: 86
| 	Minor (reclaiming a frame) page faults: 4703
| 	Voluntary context switches: 4805
| 	Involuntary context switches: 274
| 	Swaps: 0
| 	File system inputs: 48384
| 	File system outputs: 5680
| 	Socket messages sent: 0
| 	Socket messages received: 0
| 	Signals delivered: 0
| 	Page size (bytes): 4096
| 	Exit status: 0
`----

OTOH, if one does specify the filename as an argument to commit, git uses almost 300 Megs of VM and the numbers look more like:

,----« gtime -v git commit -m 'make oldconfig' .config »
| [master 4db1e8b] make oldconfig
|  1 files changed, 1 insertions(+), 1 deletions(-)
| 	Command being timed: "git commit -m make oldconfig .config"
| 	User time (seconds): 1.82
| 	System time (seconds): 1.80
| 	Percent of CPU this job got: 3%
| 	Elapsed (wall clock) time (h:mm:ss or m:ss): 1:45.72
| 	Average shared text size (kbytes): 0
| 	Average unshared data size (kbytes): 0
| 	Average stack size (kbytes): 0
| 	Average total size (kbytes): 0
| 	Maximum resident set size (kbytes): 0
| 	Average resident set size (kbytes): 0
| 	Major (requiring I/O) page faults: 1609
| 	Minor (reclaiming a frame) page faults: 21363
| 	Voluntary context switches: 10707
| 	Involuntary context switches: 620
| 	Swaps: 0
| 	File system inputs: 361192
| 	File system outputs: 11296
| 	Socket messages sent: 0
| 	Socket messages received: 0
| 	Signals delivered: 0
| 	Page size (bytes): 4096
| 	Exit status: 0
`----

Git should be able to do the latter operation as efficiently as it can do the former operation.

-JimC

James Cloos <cloos@jhcloos.com> writes:

When you do:

    git add something && git commit

the commit step is just "write the index out as a tree, create a commit object to wrap that tree object". It never has to look at your work tree and is a very cheap operation.

On the other hand, if you do:

    some other random things && git commit pathspec

the commit step involves a lot more operations.  It has to do:

    - create a temporary index from HEAD (i.e. ignore the modification to
      the real index you did so far with your earlier "git add");

    - rehash all the paths in the work tree that matches the pathspec and
      add them to that temporary index; and finally

    - write the temporary index out as a tree, create a commit object to
      wrap that tree object.

The second step has to go to your work tree, and if you have a slow disk, or your buffer cache is cold, you naturally have to pay.

So it is not surprising at all if you observe that the latter takes more time and resource than the former, although there could be something wrong in your set-up that you need to spend 300M for it. It is fundamentally a more expensive operation.