Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Bernard A Badger" <bab AT vx DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Cygwin is SLOW
Date: Wed, 17 Jul 2002 09:30:12 -0400
Message-ID: <INEKLKBFCDBPKMKAJLMDEEBCCGAA.bab@vx.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <002b01c22d5f$5412daa0$a50aa8c0@pcse5>
Importance: Normal


> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com]On Behalf
> Of BiDuS
> Sent: Wednesday, July 17, 2002 2:58 AM
> To: cygwin AT cygwin DOT com
> Subject: RE: Cygwin is SLOW
>
>
> Ok, maybe my English was bad enough to confuse you about my question.
> I meant "why is there a so big difference between executing one script (say
> the fast one) on a distant file and on a local file ?",
> the path to chmod.exe being the same for both execution (am I wrong ?).
> I quoted my results and drop other stuff.

> >> I've tried both slow and fast perl scripts on my machine (AMD XP1700,
> W2K)
> >>
> >> If  test.file is on a local directory
> >>
> >> $ perl fastchm.pl
> >> 2923.6 chmods per sec
> >>
> >> if test.file is on a mounted directory (through a symlink)
> >>
> >> $ perl fastchm.pl
> >> 143 chmods per sec
> >>
> >> Could anyone explain the performance ratio for both scripts ???
>
> [SNIP]
Because it _is_ a distant file.
C'mon, do you expect the network to set-up a connection and check authentication
and modify the file and return the results as quickly as a local file?
If you question the particular ratio, 20:1, you need to know a _lot_ of
specifics
about your system, before you get anywhere close to an answer.
(Disk speed, disk block caching, controllers, latency, network protocol,
network file system.)

With a local file, the "file" modifications are probably being done in a
in-memory image.  It doesn't have to be synced to disk.
Over the network, you don't have access to that cache, and must re-connect.
Clever implementations of Network File Systems may be able to hide
much of this difference, by, say, distributing the whole file system,
but evidently Windows doesn't do whatever it takes.

One typical point of overhead for the network file system, is opening the file.
Even though you have "mapped" the drive, opening the file still requires network
access, because it may have changed since you last closed it.
NFS are usually optimized for file access, rather than directory access.
This can be a bottleneck for sysadmin type things where you manipulate a lot of
metadata.  But most customers are not sysadmins, they just want their flat files
and databases to run fast.  (Well, they complain more about them anyway.)
>
> >> I got a wider gap for small c program opening and closing about 650 files
> >> It takes 0.750 s for local files and about 2 s for distant files
> >> On the linux machine, it's just 0.1 s for distant files...
> >>
> >> Is the _open() routine guilty ?
> >> Is it linked to the unix AND dos path compatibility ?
> >> Anyone as a hint to speed this up ?
This just points up the fact that it's your network access, not Cygwin, that
is so slow.  Network file system optimization is, I suppose, Off Topic.

> I noticed you mentionned the influence of the PATH length upon the global
> performance
> and I keep invastigating... (path convertion routine)
The PATH should only affect the slowchm.pl, as fastchm.pl doesn't repeatedly
scan the PATH.  It's the system() or exec() call that requires looking up
"chmod" in the path.  "test.file" is only "looked up" in the local directory.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/