On Sun, Dec 14, 2003 at 12:46:54PM +0100, Sven Neumann <sven@xxxxxxxx> wrote:
> This sounds like if you had a clue on what is causing the slowliness
> of running configure on Cygnus.
The biggest reason is very slow fork(), followed by extremely slow
select(), filehandle operations, pipes and much more.
Basically, windows makes it very difficult to do simple things, for
example, there is no way to simply wait for events, every type of object
needs a different waiting paradigm. So to use select, cygwin has to start
threads per type of filehandle etc... you can imagine how slow that
becomes.
And fork is simply not window's model of managing processes (instead you
use CreateProcess with 10 arguments...).
Windows isn't based on an efficient process model. If you want to do
"IPC", you 'simply' load a dll into your memory area and start some
threads (which is being called "ActiveX" in the hipper areas of this
world). Real IPC is slow, and not really meant to be used.
Since configure scripts use fork() and IPC a lot, that's why it's slow.
> software on Windows and noticed this shortcoming as well. I wondered
> what might be the cause and if there are ways to work around it. Are
> there any?
Cygwin tries to be correct first, fast second. I don't think there is any
workaround, as it's not really a bug that could be workarounded. One could
sacrifice posix compatibility to some degree to get faster, but configure
scripts will likely always be slow, even if e.g. the sus spawn facilities
are being used.
One "workaround" would be to link in most shell-utilities into your shell,
that would certainly help, to some extent, but don't expect wonders.
This is being written by somebody who doesn't think very highly of the
windows API, keep that in mind :) I am convinced that the major reason for
bad software under windows is the extremely complicated, overloaded and
non-orthogonal API.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
