Re: [Mingw-w64-public] SJLJ vs DW2 - fact checking

[Koehne K. <Kai...@di...>]

> -----Original Message-----
> From: Ruben Van Boxem [mailto:van...@gm...]
> Sent: Tuesday, February 26, 2013 10:01 AM
> To: min...@li...
> Subject: Re: [Mingw-w64-public] SJLJ vs DW2 - fact checking
> 
> 2013/2/26 Koehne Kai <Kai...@di...>
> 
> 
> 	Hi there,
> 
> 	For Qt 5.0 we've been packaging a 32bit mingw-builds toolchain with
> SJLJ exception handling. However, it now became clear that the performance
> penalty for SJLJ is quite heavy (e.g. 25% for startup of a medium-sized
> application, up to 3x slow down for a small test application, see also
> https://bugreports.qt-project.org/browse/QTBUG-29653 ). I'm therefore
> inclined to recommend a switch to a DW2 based version for Qt 5.1.
> 
> 	There's lots of bits and pieces about DW2 vs SJLJ  exception handling
> on the web, but I'd like to check with you whether I got the following facts
> right:
> 
> 	 - SJLJ incurs a performance penalty even when no exceptions are
> thrown at runtime. The penalty is >10% for typical applications.
> 	 - DW2 potentially generates bigger libraries. The overhead however
> is not big (< 10%) for typical applications.

Actually I had a second look on this. It seems that the differences in size are minor for code that is compiled with exceptions enabled. However, for libs that are compiled with -fno-exceptions the size of the dw2 toolchain is somewhat bigger than the same code compiled with sjlj. E.g. when compiling Qt5Core without exceptions the size of the dll with the sjlj toolchain is 3,342 MB, vs 3,826 MB with DW2. With exceptions enabled, the size is 4,164MB (sjlj) vs 4,125MB (dw2).

> 	 - if using DW2, things will go wrong (crashing?) if one tries to throw
> exceptions through stack frames not compiled with DW2 (typical case:
> Windows callbacks).
> 	    - following from the above, one should never mix code compiled
> with DW2, and code compiled with SJLJ, in one project.
> 	 - mingw.org has switched to DW2 since a while.
> 	 - For gcc 4.7/64 bit, only SJLJ is available. gcc 4.8 will feature SEH,
> which solves the performance problems SJLJ has. Anyhow, gcc 4.8 most
> probably won't feature SEH for 32 bit.
> 
> 	Anything I missed?
> 
> 
> 
> This is pretty complete. It is also the first time I saw figures that high in the
> disadvantage of SJLJ EH. The testcase is weird though: turning off exceptions
> (compiling with -fno-exceptions) should remove all EH code and related
> slowdowns if I'm not mistaken... 

The slowdown of the benchmark stems from Qt5Core, which is compiled with exceptions enabled by default. If I manually disable exceptions in QtCore 'by hand' (commenting out CONFIG+=exceptions in qtcore.pro), the benchmark differences go down from 300% slowdown to about 10 % . That is, there's no easy way for applications to fix this.

> There is a high lack of profiling in this
> discussion about performance. There are literally tens of other things that
> might be affecting performance. To name one thing, the different mingw-
> builds version used in the comparison. 

Fair enough. I now did the same tests (running the benchmark attached to the bug report + profiling creator startup times) with both x32-4.7.2-release-posix-dwarf-rev8.7z and x32-4.7.2-release-posix-sjlj-rev8.7z , with almost the same results. I tried to really use the same configuration on both tests, did a release build etc. I might still of course screwed it somewow, so it would be cool  to have numbers from other tests/people, too :)

Just for the record, here's the configuration I used:

Compiled ICU-49, Qt-5.1 (without webkit), configure line for Qt 5: 'configure -opensource -confirm-license -nomake examples -nomake tests -debug-and-release -release'
Compiled both creator (2.6.2) and benchmark with 'qmake -r CONFIG+=release'.

The creator startup times are a median of 10 different runs with

'start /high bin\qtcreator -profile -settingspath D:\inexistingdir'

And checking for the time span between the first debug message, and the last message, in windows debugger log (dbgview).

Regards

Kai