This is the mail archive of the cygwin 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: Serious performance problems (Gerrit/Danny please comment)

Danny Smith wrote:

Re: Serious performance problems (Gerrit/Danny please comment)
From: Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>
To: cygwin at cygwin dot com
Date: Sat, 28 May 2005 14:57:20 -0400
Subject: Re: Serious performance problems (Gerrit/Danny please comment)
References: <>
Reply-to: cygwin at cygwin dot com


On Sat, May 28, 2005 at 01:24:31PM +0200, Vaclav Haisman wrote:

Somebody mentioned that malloc implementation could be the problem. Dunno. I
has also crossed my mind that another difference between FreeBSD and Cygwin


implementation of C++ exceptions. Maybe the SJLJ implementation that Cygwin
AFAIK uses has too big overhead.

To test this theory, I just tried replacing Cygwin's "Unwind" functions with those from mingw and saw a noticeable speed up in the execution of this program. I did this by extracting the contents of mingw's libgcc to a directory and then including unwind-c.o and unwind-sjlj.o on the command line when linking the test case. I had to modify the test case by adding these two lines to the bottom:

 int __mingwthr_key_dtor;
 int _CRT_MT;

to avoid undefined symbol errors so this is obviously not intended as a
complete solution.

On doing this, the program went from taking 25 seconds to execute to
taking 7 seconds to execute.  That's still 4x slower than mingw but it
is, nonetheless, a noticeable difference.

Gerrit and Danny do you know what the difference between the mingw and
cygwin implementations of these functions might be?

I too suspect sjlj exceptions to be the problem. This has already been
reported on GCC lists:

The sjlj overhead affects both cygwun and mingw, but cygwin has the
additional overhead of posix threads to ensure thread-safe allocation
and destruction of structures used by exception handling, while mingw
uses win32api directly
(In CRT_MT == 0 case, it doesn't even bother cleaning up)

As I thought before, the only difference is buried in w32-shared-ptr.c:

$ g++ -o cygspd-mingw cygspd-mingw.o

$ time ./cygspd-mingw cygspd.dat

real    0m51.071s
user    0m50.108s
sys     0m0.046s

cgf, your box must be really fast if this lasts half the time than it
lasts for me and I have already a really fast box;)

$ g++ -o cygspd-mingw cygspd-mingw.o w32-shared-ptr.o

$ time ./cygspd-mingw cygspd.dat

real    0m8.049s
user    0m7.015s
sys     0m0.093s

Is this call in w32-shared-ptr.c really needed here?

/* recreate atom after fork */
pthread_atfork (NULL,NULL,__w32_sharedptr_fixup_after_fork);

Enabling Dwarf2 exceptions helps a lot, since it eliminates the need for
the code for these object in f function prologue.

Sigh! Gerrit -- =^..^=

Unsubscribe info:
Problem reports:

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