From: noer AT cygnus DOT com (Geoffrey Noer) Subject: Re: Performance 4 May 1997 21:38:15 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199705050126.SAA13688.cygnus.gnu-win32@rtl.cygnus.com> Content-Type: text Original-To: bje AT air DOT net DOT au (Ben Elliston) Original-Cc: gnu-win32 AT cygnus DOT com In-Reply-To: from "Ben Elliston" at May 3, 97 06:03:31 pm X-Mailer: ELM [version 2.4 PL23] Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 AT cygnus DOT com - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".