Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Wed, 15 Mar 2000 18:45:12 +0300
From: Egor Duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.029) S/N A0F2A05A
Reply-To: Egor Duda <deo AT logos-m DOT ru>
Organization: DEO
Message-ID: <8781.000315@logos-m.ru>
To: Corinna Vinschen <corinna AT vinschen DOT de>,
        cygdev <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re[2]: Cygwin performance (was [ANN] PW32 the...)
References: <38CF6031 DOT 7D7A28BB AT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Corinna Vinschen corinna AT vinschen DOT 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 AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19