threads / rfc / 17586

v3, 9 partsRe: [PATCH/RFC v3 7/9] write_entry(): use fstat() instead of lstat() when file is open

Subject: Re: [PATCH/RFC v3 7/9] write_entry(): use fstat() instead of lstat() when file is open

## tl;dr

One message between Feb 5, 2009 and Feb 5, 2009. Diffs are folded; open one to read it.

replies: 0people: 1as markdown or json

Kjetil Barvik· Feb 5, 2009, 10:46 UTC · lore
* Kjetil Barvik schrieb:
| And, yes, since each lstat() call cost approximately 44 microseconds
| compared to 12-16 for each lstat() on my Linux box, there was a little
                             ^^^^^^^ fstat()?
  Yes, is is the fstat() call which takes 12-16 microseconds on my Linux
  box.
| performance gain from this patch.
* Johannes Sixt <j.sixt@viscovery.net>
| This does look like a good gain. But do you have hard numbers that back
| the claim?
|
| If you can squeeze out a 10% improvement on Linux with this patch, we
| should take it, and if it turns out that it doesn't work on Windows, we
| could trivially throw in an #ifdef MINGW (or even #ifdef WIN32 if Cygwin
| is affected, too) that skips the fstat() optimization.
| 
| But we really should have numbers that justify this effort.
  I have been working on a long running test script latly, but then I
  started to play with the 'git repack' command, so it was not top
  priority.  But, I can finish the script today, and run it while I am
  sleeping tonight.
| BTW, the statement from the Windows documentation was:
|
|  "The only guarantee about a file timestamp is that the file time is
|   correctly reflected when the handle that makes the change is closed."
|
| In the case of this patch, the timestamp is queried via the handle
| that made the change, and in this case special case the timestamp
| could be correct nevertheless. The guarantee doesn't cover this case,
| but it would be natural, and perhaps it Just Works?
  Yes it could perhaps "just works".  But, then I guess that when it
  does not work, the user would not notice it _except_ for more time
  used.  Since I can to this:

kjetil@localhost ~/git/git $ git status # On branch lstat_fstat_v6 nothing to commit (working directory clean) kjetil@localhost ~/git/git $ touch var.c kjetil@localhost ~/git/git $ git status # On branch lstat_fstat_v6 nothing to commit (working directory clean) kjetil@localhost ~/git/git $

  ... I think that git will have to check the content and read each byte
  and do a SHA1 of the file var.c in this case (since the timestamps do
  not match), which is a more time and CPU hungry opperation, to decide
  if there is a difference inside the file or not.
  And, maybe some other platform also have problems with this trick?
  OK, I do the time tests and let the numbers talk.
  -- kjetil

← back to recent threads