Re: Commit performance, or lack thereof

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

 



James Cloos <cloos@xxxxxxxxxxx> writes:

> 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,
> ...
> OTOH, if one does specify the filename as an argument to commit,...

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.


    
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]