Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions

[Mark Levedahl <mlevedahl@gmail.com>]

On 07/18/2013 05:49 PM, Torsten Bögershausen wrote:
> On 2013-07-18 19.50, Ramsay Jones wrote:
>>
>> Hmm, that looks good. :-D
>>
>> Torsten reported a performance boost using the win32 stat() implementation
>> on a linux git repo (2s -> 1s, if I recall correctly) on cygwin 1.7.
>> Do you have a larger repo available to test?
> (I have a 5 years old Dual Core, 2.5 Ghz, 1 TB hard disk, Win XP, cygwin 1.7)
> On that machine I can see the performance boost.
> Which kind of computers are you guys using?
>
> SSD/hard disk ?
> How much RAM ?
> Which OS ?
> Is there a difference between Win XP, Win7, Win8?
>
> [snip]
>
>
My previous results were from a Win 7 laptop, 2.7 GHz 2nd generation I7, 
8 Gig Ram, 250 GByte spinning rust drive, all formatted NTFS.

Here's some more results, running WinXP in VirtualBox on my older Linux 
laptop (2.5 GHz Penryn dual core, 500 GByte spinning rust, virtual file 
system is NTFS). First, results using Ramsay's last patch on pu adding 
the fast_lstat: Timing results are after first doing 5 'git status runs' 
to assure the cache is hot:

% using the fast_lstat and friends...
/usr/local/src/git>time git -c core.filemode=false status >& /dev/null

real    0m0.469s
user    0m0.062s
sys     0m0.436s
/usr/local/src/git>

/usr/local/src/git>time git -c core.filemode=true status >& /dev/null

real    0m0.719s
user    0m0.030s
sys     0m0.686s
/usr/local/src/git>

And now the same. but using Ramsay's first patch that removes all win32 
stat stuff and forces everything to go through Cygwin's normal stat/fstat:
% stat - with / without core.filemode, no win32 stats
/usr/local/src/git>time git -c core.filemode=false status >& /dev/null

real    0m0.328s
user    0m0.093s
sys     0m0.264s
/usr/local/src/git>

/usr/local/src/git>time git -c core.filemode=true status >& /dev/null

real    0m0.625s
user    0m0.124s
sys     0m0.500s
/usr/local/src/git>


Unlike the results on the fast Win7 laptop, the above show statistically 
significant slow down from the fast_lstat approach. I'm just not seeing 
a case for the special case handling, and of course Junio has already 
voted with his preference of removing the special case stuff as well.

Mark