strange crashes on invocation

Corinna Vinschen
Sat Sep 25 19:50:00 GMT 2010

On Sep 25 15:19, Christopher Faylor wrote:
> On Sat, Sep 25, 2010 at 08:46:25PM +0200, Corinna Vinschen wrote:
> >On Sep 24 18:36, Corinna Vinschen wrote:
> >> On Sep 24 10:07, Christopher Faylor wrote:
> >> > On Fri, Sep 24, 2010 at 12:48:50PM +0200, Corinna Vinschen wrote:
> >> > The other motivation for the autoload stuff was supposed to be reducing
> >> > the runtime link cost of resolving symbols that would never be used.  It
> >> > would be interesting to see if there is any noticeable performance change.
> >> > I could see it either getting faster or slower.
> >> 
> >> I'll do some speed comparisions over the weekend.
> >
> >The results are terrible.  There are three system libs which have no
> >visible impact when being linked against (ws2_32, secur32, rpcrt4).  The
> >others have a performance *hit* from 2.5% (user32), up to 25% (iphlpapi,
> >shell32).  In no way do the results support the point I was trying to
> >make.  Autoloading rulez.
> Wow.  I'm quite surprised.  I didn't think it would make any discernible
> difference.  I only implemented this stuff on a whim to clean up all of
> the "if (this_is_windows_version_blah) ... else ..." stuff.  I thought it
> might have a positive performance impact but I never actually checked.

I tested this on a (real, not virtual) W7 32 bit system and I
concentrated on the fork/exec performance.  One frustrating problem is
that these results may be very different on different Windows versions
since the kernel has been rewritten in big parts from one major kernel
version to the other.  Also, W7 has a lot more DLLs "under the hood"
than any former system.  However, since W7 is the current system, it's
the one which sets the mark.

What bugged me even more while testing was the waywardness of the
system.  At one point I had a constant slowdown of all tests by about
20% for the exact same test DLLs for no apparent reason.  Officially the
system was doing nothing but running my performance test.  Inofficially
the OS was doing "something" which did neither show up in Task Manager,
nor did the hard disk show any signs of activity.

So, I trust my results only up to a point.  The only result I'm pretty
sure of is that it doesn't get *better* by linking against the DLLs.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list