Mail Archives: cygwin-developers/2000/03/15/09:12:04
On Wed, Mar 15, 2000 at 11:04:33AM +0100, Corinna Vinschen wrote:
>I have moved this thread to cygwin-developers because those
>details are not of interest in the base list, IMHO.
>
>Egor Duda wrote:
>> [...]
>> basically, reason is following: ls uses "stat" syscall to obtain file
>> information. stat returns a handful of parameters, including inode,
>> permissions and others. to obtain _all_ that info, cygwin must open file
>> (see stat_worker function at winsup/cygwin/syscalls.cc). opening every
>> file on network share is pretty slow.
>>
>> luckily, most of time application don't need _all_ stat information.
>> for example, if you need to get file time or owner or size only,
>> there's no need to open file. so, some time ago i've proposed to make
>> cygwin1.dll export function "stat_lite", which works similar to
>> "stat", but receives additional flags, showing which fields are of
>> [...]
>
>No matter of the possible speed up, I don't like this solution
>because of...
>
>> note: you have to recompile your application to utilize "stat_lite"
>> function.
>
>... that result.
I think that Egor also provided a CYGWIN environment variable setting
method, too.
>I'm absolutely sure to get a speed up by the following, without
>the need of another stat-function:
>
>The current implementation of fhandler_disk_file::fstat() calls
>three different functions which each opens the file independently:
>get_file_owner(), get_file_group(), get_file_attribute(). I've
>already planned to eliminate the first two functions. Instead,
>the complete functionality should be offered by get_file_attribute().
>This makes sense, because get_file_attribute already knows user
>and group. I hope to increase speed noticable that way.
>
>Ah, one hint: This wouldn't change anything when ntsec is OFF. But
>in that case neither get_file_owner() nor get_file_group() nor
>get_file_attribute() could slowing down things...
I think that the big slowdown happens in counting the files in
a directory to update the "nlinks" field in stat (or whatever
it's called).
I went over the file handling code a year or so ago and attempted
to eliminate multiple hits to the disk as much as possible. I'm
sure that more can be done here, though.
Maybe we should just detect when a file or directory is remote
and not do some of the more expensive operations.
I would like the ability to be able to set attributes on an executable
something like:
chattr --stat-lite ls.exe
So that ls would always use "stat-lite" from then on. Other options
would be:
chattr --binmode cat.exe
chattr --use-ntsec cp.exe
chattr --fix-all-existing-bugs cygwin1.dll
etc.
cgf
- Raw text -