{"thread":{"id":"17586","subject":"Re: [PATCH/RFC v3 7/9] write_entry(): use fstat() instead of lstat() when file is open","startedAt":"2009-02-05T10:46:24Z","lastAt":"2009-02-05T10:46:24Z","messageCount":1,"participants":["Kjetil Barvik"],"isPatch":true,"patchVersion":3,"patchTotal":9},"messages":[{"id":"103320","messageId":"86fxit9n5r.fsf@broadpark.no","threadId":"17586","inReplyTo":null,"subject":"Re: [PATCH/RFC v3 7/9] write_entry(): use fstat() instead of lstat() when file is open","fromName":"Kjetil Barvik","fromEmail":"barvik@broadpark.no","sentAt":"2009-02-05T10:46:24Z","receivedAt":"2009-02-05T10:46:24Z","isPatch":true,"sender":{"key":"barvik@broadpark.no","avatar":null},"body":"* Kjetil Barvik schrieb:\n| And, yes, since each lstat() call cost approximately 44 microseconds\n| compared to 12-16 for each lstat() on my Linux box, there was a little\n                             ^^^^^^^ fstat()?\n\n  Yes, is is the fstat() call which takes 12-16 microseconds on my Linux\n  box.\n\n| performance gain from this patch.\n\n* Johannes Sixt <j.sixt@viscovery.net>\n| This does look like a good gain. But do you have hard numbers that back\n| the claim?\n|\n| If you can squeeze out a 10% improvement on Linux with this patch, we\n| should take it, and if it turns out that it doesn't work on Windows, we\n| could trivially throw in an #ifdef MINGW (or even #ifdef WIN32 if Cygwin\n| is affected, too) that skips the fstat() optimization.\n| \n| But we really should have numbers that justify this effort.\n\n  I have been working on a long running test script latly, but then I\n  started to play with the 'git repack' command, so it was not top\n  priority.  But, I can finish the script today, and run it while I am\n  sleeping tonight.\n\n| BTW, the statement from the Windows documentation was:\n|\n|  \"The only guarantee about a file timestamp is that the file time is\n|   correctly reflected when the handle that makes the change is closed.\"\n|\n| In the case of this patch, the timestamp is queried via the handle\n| that made the change, and in this case special case the timestamp\n| could be correct nevertheless. The guarantee doesn't cover this case,\n| but it would be natural, and perhaps it Just Works?\n\n  Yes it could perhaps \"just works\".  But, then I guess that when it\n  does not work, the user would not notice it _except_ for more time\n  used.  Since I can to this:\n\nkjetil@localhost ~/git/git $ git status \n# On branch lstat_fstat_v6\nnothing to commit (working directory clean)\nkjetil@localhost ~/git/git $ touch var.c\nkjetil@localhost ~/git/git $ git status \n# On branch lstat_fstat_v6\nnothing to commit (working directory clean)\nkjetil@localhost ~/git/git $ \n\n  ... I think that git will have to check the content and read each byte\n  and do a SHA1 of the file var.c in this case (since the timestamps do\n  not match), which is a more time and CPU hungry opperation, to decide\n  if there is a difference inside the file or not.\n\n  And, maybe some other platform also have problems with this trick?\n\n  OK, I do the time tests and let the numbers talk.\n\n  -- kjetil\n"}]}