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: c++ code executes very slowly - sjlj EH to blame?


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
>>terms.
>>
>>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.
>

<ding-dong-lurker.wav>
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
that
throw exceptions from a foreign function) has not

A 4.0 patch to enable DW2 unwind is at:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01989.html

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.

Danny


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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