This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re[2]: Cygwin performance (was [ANN] PW32 the...)


Hi!

Corinna Vinschen corinna@vinschen.de 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
>> [...]

CV> No matter of the possible speed up, I don't like this solution
CV> because of...

>> note: you have to recompile your application to utilize "stat_lite"
>> function.

CV> ... that result.

well, i know many apps are compiled oob with cygwin, still frequently
application should be patched. so, if someone's concerned about
porting application with cygwin, there may be several possible goals:

1) make application work,
2) make it work efficiently,
3) make it use windows-specific features (such as logging in to windows
domain, writing windows event logs, etc.)
4) ...

each of this goals may require changing the sources. i don't see why

#ifdef __CYGWIN__
  #define CYGWIN_STAT_LITE_FLAGS (STAT_LITE_TIME | STAT_LITE_SIZE | STAT_LITE_OWNER | STAT_LITE_PERM)
  cygwin_stat_lite (path, buf, CYGWIN_STAT_LITE_FLAGS);
#else
  stat (path, buf);
#endif

is so much different from

#ifdef __CYGWIN__
  CreateProcessAsUser (...);
#else
  // ... some unix-way code
#endif

CV> I'm absolutely sure to get a speed up by the following, without
CV> the need of another stat-function:

CV> The current implementation of fhandler_disk_file::fstat() calls
CV> three different functions which each opens the file independently:
CV> get_file_owner(), get_file_group(), get_file_attribute(). I've
CV> already planned to eliminate the first two functions. Instead,
CV> the complete functionality should be offered by get_file_attribute().
CV> This makes sense, because get_file_attribute already knows user
CV> and group. I hope to increase speed noticable that way.

hmm. i hadn't looked in ntsec code for a while, but some time ago,
afai remember, those functions didn't open file. am i wrong, or
something have changed recently?

CV> Ah, one hint: This wouldn't change anything when ntsec is OFF. But
CV> in that case neither get_file_owner() nor get_file_group() nor
CV> get_file_attribute() could slowing down things...

anyway, CreateFile () on slow network links is much slower then
FindFirstFile (). So if application wants to know only file size
and calls "stat", it can speed things up just by hinting that it needs
only file size. with that hint, "stat" won't call CreateFile(), but
only FindFirstFile ()

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]