This is the mail archive of the 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]
Other format: [Raw text]

Re: cygwin performance

Pierre A. Humblet wrote:

Christopher Faylor wrote:

On Wed, Oct 22, 2003 at 09:40:10PM +0200, Hannu E K Nevalainen wrote:

From: Linda W.
Sent: Wednesday, October 22, 2003 12:49 AM

Perhaps it is unavoidable, but I see things like find doing 2
'opens' /file when it is searching for files...can't it just do a
'stat' of some nature? does it need to do an open, let alone 2?


The reason why stat() opens a file even with ntsec is to use

This may be something that would be a special case, but if I'm just looking for
names -- why does it need to do a stat? Or is that necessary to determine if a name
is a directory?...(*ouch*)...But native WinXP find displays date/time all the properties of the
files found -- and one can search on "oldness", size...etc -- so it must be possible to get that
info w/o opening? Or something else is causing a slowdown. I mean do a Windows find both
on a cold reboot and a 2nd pass (see differences attributable to cache), then do same with
find command. You'll see find takes alot longer in both cases though both cases usually speed up.

It's been a while, but I think if I did a win-find first followed by a cyg-find, there was no cache
effect for cyg-find, but if I did cyg-find first, I believe there was a cache effect speedup for winfind.

It seemed like the cyg (gnu) find was looking for more information than was needed (and that
wasn't pulled in by the win-find command.

I believe that the major culprit is looking for executable files. If I have
understood things correctly.

$ mount -h | grep exe
-x, --executable treat all files under mount point as executables
-E, --no-executable treat all files under mount point as
-X, --cygwin-executable treat all files under mount point as
cygwin executables

AFAIK this applies only when (smb)ntsec isn't in effect. Correct me if I am wrong.

FYI -- I'm not running with any smb mounted disks in my path and all of my disks are FAT32.
Note: Sandra tests of file performance between FAT32 and NTFS on the same disk show NTFS
running about 3x slower than FAT32 (was running benchmarks to compare drive access speeds
using IDE/USB 2.0 and Firewire. Clear winner was IDE (no surprise) with Firewire suffering maybe a
4-5% drop, but USB 2.0...ran about 5 times slower (which was still 10x faster than USB 1.1 tests).


Unsubscribe info:
Problem reports:

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