Mail Archives: cygwin/2010/06/01/17:42:18
I think there are a lot of use cases where the extra information (ACL
information *I assume* is the majority of the problem) is unnecessary.
For most of the applications filename, size, and the three dates are all
that is necessary. So cygwin stat is overkill. So if I can tell the
emulation layer (via an environment flag) or the actually utility
(bash/ls/make/find/du) via a command line switch, I think I can save a lot
of time waiting.
Just to highlight how bad this problem is. I have a network drive with
681 sub directories and approximately 90k files. A time comparison for
getting directory information as follows:
*DOS "dir /s" takes 17 seconds.
*Cygwin "ls -lR" takes 5950 seconds (that's almost two hours).
*msls -lR takes 55 seconds.
*myls (see code below) takes 7 seconds.
Each test was done twice and after a reboot to make sure there was no
caching involved.
To be clear, Cygwin ls is 850X slower.
msls can be retrieved here http://utools.com/msls.htm
myls is as follows:
int main( int arc, char *argv[] )
{
dodir( "p:\\dl" );
}
int dodir( char *dir )
{
WIN32_FIND_DATA findData;
HANDLE f;
char spec[ 1024 ];
char fname[ 1024 ];
printf( "DIR %s\n", dir );
sprintf( spec, "%s\\*.*", dir );
f = FindFirstFile( spec, &findData );
do
{
sprintf( fname, "%s\\%s", dir, findData.cFileName );
if ( findData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY )
{
if ( ( strcmp( findData.cFileName, "." ) != 0 ) && ( strcmp(
findData.cFileName, ".." ) != 0 ) )
{
dodir( fname );
}
}
else
{
printf( "%s %d\n", fname, findData.nFileSizeLow );
}
}
while( FindNextFile( f, &findData ) );
FindClose( f );
}
> Christopher Wingert schrieb:
>> I assume POSIX compatibility. However, I bet there are cases where one
>> can sacrifice compatibility for performance (configurable with an
>> environment flag of course).
>>
>> See
>> http://marc.info/?l=git&m=122278284210941
>> for an example.
>
> This git do_stat is for only meant for a 50% implementation of relative
> paths known before, and therefore onyl useful to certain apps, but it
> can never be useful for the cygwin1.dll layer, because cygwin has to
> provide the POSIX compat. layer, and not 50% cut-throughs for apps which
> don't need the other 50%. ACL, mounts, symlinks, inode.
>
> A better chaching stat or an cygwin extension for relative deeper only
> would be possible, but a better caching stat would need more memory and
> sacrifice speed for the first stat.
> A fast relative stat is very unlikely to be #IFDEF's in some apps just
> for us. So it's more likely that those apps which might need it, come up
> with their own 50% less, but 50% faster bits, as git did.
>
>>> On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote:
>>>> I was looking into speeding up stat() performance. More specifically
>>>> bash, ls, test, stat performance. I've seen the subject come up
>>>> before.
>>>> Git recently implemented a native Win32 work around. Are there any
>>>> cygwin
>>>> patches around?
>>>
>>> If there was a way to make stat() faster why wouldn't it be in the
>>> source
>>> code already?
> --
> Reini Urban
> http://phpwiki.org/ http://murbreak.at/
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -