This is the mail archive of the
mailing list for the Cygwin project.
Re: c++ code executes very slowly - sjlj EH to blame?
- From: Danny Smith <dannysmith at clear dot net dot nz>
- To: adam_m_mckee at yahoo dot ca
- Cc: Cygwin <cygwin at cygwin dot com>
- Date: Thu, 16 Dec 2004 22:33:31 +1300
- Subject: Re: c++ code executes very slowly - sjlj EH to blame?
- Reply-to: Danny Smith <dannysmith at users dot sourceforge dot net>
Larry Hall wrote:
>True but the way I read that conversation was that DWARF2
>EH worked if callbacks weren't used or would work with
>callbacks so long as -fexceptions was used. Maybe I read
>that incorrectly though.
That is correct. Maybe we can convince ReactOs to release a win32api built
with -fexceptions and DW2 unwind tables.
>>My goal is to build gcc/g++ that use Dwarf2 EH. A
>>compiler with working EH will be able to run my test
>>program without aborting. So far I have built several
>>versions of gcc, all of which have the abort() EH,
>>which is equivalent to having _no_ EH in practical
>>Maybe Danny Smith has some thoughts about this, since
>>he has apparently been at least partially successful
>>in getting DWARF2 EH to work on cygwin.
>Yes, I expect he'll chime in.
FWIW, Dwarf2 unwind worked without any complaints (that I am aware of)
from cygwin users in a GCC-3.2 (cygming special) release. One of the two DW2
bug reports by mngw users (stdcall vs fomit-frame-pointer vs
-mno-accumulate-outgoing-args) has been fixed in GCC. The other (callbacks
throw exceptions from a foreign function) has not
A 4.0 patch to enable DW2 unwind is at:
GCC is now in Stage 3 of development cycle (regression fixes only)
I plan to submit a revised patch when 4.0 branches. So maybe 4.1
>>Another question for anyone at all: any ideas why sjlj
>>is so crap-tastically slow on cygwin? I can't believe
>>that sjlj EH has nearly such a huge hit on other
>>targets. If sjlj it is the sole perpetrator of the
>>slowdown, then it is doing a very very effective job
>>of slowing things down.
Depends. If you're app makes only limited use of exceptions, sjlj can be
more efficient. However, since operator new can throw exceptions, the
cost of sjlj can add up very quickly. I think the default use of the
simple new-based allocator in gcc-3.4.x libstdc++ (rather than a more
efficient pool allocator) also compounds the problem.
I wouldn't blame everything on sjlj. C programs that do any file I/O
are also crap-tastically slow on windows compared to glibc targets.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html