RE: performance

RE: performance

[paul van der Meij]

the slow performance of cygwin I reported on 15-3 was not caused by
cygwin.
A corrupted FAT partition was the cause.

I apologize for this wrong accusation.

-- 
Paul van der Meij, 		Hengelo,	 the Netherlands

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Performance

[Geoffrey Noer]

Ben Elliston wrote:
> 
> Someone on another mailing list suggested the applications ported to Win32
> using Cygwin are not up to scratch.
[...]
> I don't understand why this might be: the compiler produces native x86
> (and presumably very good!) code for the user space code and for UNIX
> system calls, they would be handled by the DLL with a secondary call into
> the Windows kernel.

I think it really depends on what you're trying to achieve.  Let me see
if I can explain what I think is going on performance-wise.

The cygwin.dll is a porting library that includes libc and libm as
well as a subset of standard POSIX and misc other common Unix library
calls.  The intention is that the Unix semantics will be preserved
such that porting Unix apps will be as painless as possible.  Some
standard Unix API calls (fork(), for example) are painfully slow under
Cygwin32 because the Win32 API differs a lot with respect to the Unix
API in terms of what's optimized/easily possible.  In addition
to some specific calls being slow, there is a certain amount of overhead
associated with the cygwin.dll because it has to maintain its own process
table, file descriptors, etc...

In terms of raw execution speed, it is almost certainly better to
rewrite Unix software entirely for Win32 than use Cygwin32.  However,
execution speed isn't the only consideration.  You'd lose out on the many
advantages of having a single source base and would have to put in a lot
of additional time and effort as well.

So there are inherent performance problems with using a Unix portability
library to port Unix code to Win32.  The other factor is that we have
been concentrating our efforts on correctness rather than on optimizing
performance.  I expect performance will become more of an issue as
the Cygwin32 library matures.

Now what about performance problems when doing plain old native Win32
programming?  Unless you use the Minimalist GNU Win32 package from Colin
Peters (see http://www.fu.is.saga-u.ac.jp/~colin/gcc.html ), which allows
you to use Microsoft libraries instead of the Cygwin32 library, you
automatically use libc/libm in the cygwin.dll and inherit lots of
unnecessary Unix baggage.  This slows things down unnecessarily.  I have
every reason to believe that if you use the Minimalist GNU Win32 package
for native development, you will see similar (or perhaps even better?)
runtime performance than with VC++ or another Win32 development tools
package.

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Performance

[Ben Elliston]

Someone on another mailing list suggested the applications ported to Win32
using Cygwin are not up to scratch.

I don't understand why this might be: the compiler produces native x86
(and presumably very good!) code for the user space code and for UNIX
system calls, they would be handled by the DLL with a secondary call into
the Windows kernel.

Does anyone have any performance comparisons between "Cygwin" apps and
native Win32 applications?  Is there any real performance penalty for
software with a high proportion of system calls?

Thanks,
Ben

---
Ben Elliston
<bje@air.net.au>

"For my birthday I got a humidifier and a de-humidifier. I put them in the same
 room and let them fight it out." -- Steven Wright

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".