From: Johannes Sixt <j.sixt@viscovery.net>
To: Kjetil Barvik <barvik@broadpark.no>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH/RFC v3 7/9] write_entry(): use fstat() instead of lstat() when file is open
Date: Thu, 05 Feb 2009 09:14:11 +0100 [thread overview]
Message-ID: <498A9FD3.2020601@viscovery.net> (raw)
In-Reply-To: <86tz7ayo51.fsf_-_@broadpark.no>
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()?
> performance gain from this patch.
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.
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?
-- Hannes
next prev parent reply other threads:[~2009-02-05 8:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 12:52 [PATCH/RFC v3 0/9] git checkout: more cleanups, optimisation, less lstat() calls Kjetil Barvik
2009-02-04 12:52 ` [PATCH/RFC v3 1/9] lstat_cache(): small cleanup and optimisation Kjetil Barvik
2009-02-04 12:52 ` [PATCH/RFC v3 2/9] lstat_cache(): generalise longest_match_lstat_cache() Kjetil Barvik
2009-02-04 12:52 ` [PATCH/RFC v3 3/9] lstat_cache(): swap func(length, string) into func(string, length) Kjetil Barvik
2009-02-04 12:52 ` [PATCH/RFC v3 4/9] unlink_entry(): introduce schedule_dir_for_removal() Kjetil Barvik
2009-02-04 20:54 ` Junio C Hamano
2009-02-04 20:55 ` Junio C Hamano
2009-02-04 21:32 ` Kjetil Barvik
2009-02-04 12:52 ` [PATCH/RFC v3 5/9] create_directories(): remove some memcpy() and strchr() calls Kjetil Barvik
2009-02-04 12:52 ` [PATCH/RFC v3 6/9] write_entry(): cleanup of some duplicated code Kjetil Barvik
2009-02-04 12:53 ` [PATCH/RFC v3 7/9] write_entry(): use fstat() instead of lstat() when file is open Kjetil Barvik
2009-02-04 14:01 ` Johannes Sixt
2009-02-04 18:41 ` Junio C Hamano
2009-02-04 19:53 ` Kjetil Barvik
2009-02-04 20:30 ` Junio C Hamano
2009-02-05 8:14 ` Johannes Sixt [this message]
2009-02-05 11:03 ` Johannes Schindelin
2009-02-05 17:45 ` Junio C Hamano
2009-02-06 11:06 ` Kjetil Barvik
2009-02-06 11:26 ` Johannes Schindelin
2009-02-14 17:50 ` Kjetil Barvik
2009-02-04 12:53 ` [PATCH/RFC v3 8/9] show_patch_diff(): remove a call to fstat() Kjetil Barvik
2009-02-04 12:53 ` [PATCH/RFC v3 9/9] lstat_cache(): print a warning if doing ping-pong between cache types Kjetil Barvik
-- strict thread matches above, loose matches on Subject: below --
2009-02-05 10:46 [PATCH/RFC v3 7/9] write_entry(): use fstat() instead of lstat() when file is open Kjetil Barvik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=498A9FD3.2020601@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=barvik@broadpark.no \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).