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

"Linda W." wrote:

> Has anyone done any testing on performance of cygwin utils over their
> native win
> counterparts?  The one that bothers me the most is the performance of
> cygwin "Find"
> and the windows 'find'.  If I'm just looking for filenames (find /c/
> -name \*.wav) vs.
> looking for *.wav in windows find GUI, the performance difference is
> very large (maybe
> 8-10x?).  Is this unavoidable because the way cygwin does emulation or
> can optimizations
> be performed that would benefit all programs (not just find).

I could be wrong (and I"m sure someone will correct me) but I believe
that stat()-like operations under Cygwin are particularly tricky in that
the Cygwin layer has to somehow map Windows file ACLs to the unix
style.  In particular, the 'x' bit is troublesome.  I believe Cygwin
looks at the file's contents to determine if it's executable, and
obviously this will slow things down a lot.  You can demonstrate this by
doing a 'ls -l' in a large directory.  There may be an option that you
can use somewhere to disable this for certain things.

Regarding pipelines, that sounds like a different matter entirely.  I
have noticed that creating processes is slow under Cygwin -- running
./configure is a good example of hurry up and wait.  But, I'm sure part
of this is the fact that Windows just isn't very fast at process
creation, and the voodoo the Cygwin does in order to support fork()
probably makes it much less efficient than under linux/freebsd.  There
may not be anything that can be done on this front.


Unsubscribe info:
Problem reports:

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