Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3F96F415.50301@tlinx.org>
Date: Wed, 22 Oct 2003 14:18:13 -0700
From: "Linda W." <cygwin AT tlinx DOT org>
Organization: what's organization?
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916
X-Accept-Language: en-us, en-ca, en-gb, en-nz, en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygwin performance
References: <3F95B7DE DOT 90601 AT tlinx DOT org> <NGBBLLIAMFLGJEOAJCCEKEJNDFAA DOT garbage_collector AT telia DOT com> <20031022200202 DOT GA25720 AT redhat DOT com> <3F96EB86 DOT 5641E01D AT phumblet DOT no-ip DOT org>
In-Reply-To: <3F96EB86.5641E01D@phumblet.no-ip.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



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?
>>>>>>            
>>>>>>
>
><snip>
>
>The reason why stat() opens a file even with ntsec is to use
>GetFileInformationByHandle 
>  
>
----
    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
>>>                       non-executables
>>> -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).


linda



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/