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

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, 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.


Just wondering....

As always, PTC.

-- ---> A software Engineer for CA governer? <--- ---> Georgy Russell for CA governor <--- ---> <---

Unsubscribe info:
Problem reports:

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