cygwin performance

[Linda W.]

Igor Pechtchanski wrote

>I suspect you're not comparing apples to apples here.  Later Windows
>versions run a file indexing service in the background, which makes
>finding files faster.  You might get more relevant results if you tried
>using "locate"  after an "updatedb".
>  
>
---
    Nope...apples to apples....have indexing serviced turned off.  I 
know how fast
locate is after it has used 'find' to generate updatedb.  The find 
command to generate that
db takes over an hour (indexes a few directories on net servers as 
well), but even a local-only
search can take quite a while.

>  
>
>>Even using 'perl' over combo's of cat|tr|sed|grep|more is significantly
>>faster to almost make the old unix standard scripting commands near
>>worthless (I've gotten more efficient at 1-line perl scripts ala (perl
>>-e '....').
>>    
>>
>
>You can always run these things under strace to see where the time goes.
>Many factors enter into these slowdowns, e.g., if your Cygwin is installed
>on a network drive, spawning multiple programs is likely to be much slower
>than spawning one, no matter how large.
>  
>
----
    Not on network drive....all on same drive. Hmm...didn't strace was 
around...but
I'm using "sysinternals" 'filemon" which returns all calls to the 
underlying OS.  Dunno, but am guessing
strace is tracing the "cygwin" "system" calls, not the underlying Win-OS 
calls.  in which
case it isn't a good tool to use, since a single open in the 'cygwin-os' 
could map to several
"opens" on the NT layer to emulate some 'dynamic' that exists in unix 
but not windows.

    Sysinternals site also has toosl for monitoring all registry 
accesses, tcp open ports and connected,
calls to network api layer, and a "top" "ProcEXP" tool that allows one 
to see what DLL modules are
loaded for a process, see where each thread is executing and determine 
cpu time used/thread -- as
well as allowing inspection of all handles opened by a process and 
(don't try this lightly) forcing close
a handle (on win2k and above).  But just look at 'filemon' output on 
'find' vs. ms find.  ms.find just
looks at directory entries -- while 'find' opens each file.  Why it does 
this to determine if a file
name exists is a bit obscure.

>>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?
>>    
>>
>
>Which tool do you use see this?  FWIW, I see at least one ReadFile in the
>Cygwin fstat implementation (fstat_helper in fhandler_disk_file.cc), for
>reading magic numbers to determine the executable bit.
>  
>
----
    Looking at tool that monitors NT/Win32 system calls, not cygwin 
callls.  It's the overall
efficiency of cygwin tools on top of the cygwin layer I'm looking at, 
not the efficiency of any
specific gnu program as implemented on top of a linux/cygwin layer.

-linda


>  
>
>>Just wondering....
>>tnx,
>>-linda
>>    
>>
>
>As always, PTC.
>	Igor
>  
>

-- 
         --->         A software Engineer for CA governer?         <---
         --->            Georgy Russell for CA governor            <---
         --->             http://www.georgyforgov.com              <---





--
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/