Hello Kai, 2013/2/26 Koehne Kai <kai.koe...@digia.com>: > 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.
Hmm, it is true that SjLj is slower as table-based unwind-information. That mainly caused by the need of actual executing code for it, even if exception wasn't thrown. So I am bit curious why there is a penalty of 25% on startup. An average execution-penalty of 5-10% I might could understand. Could you describe in more detail what "startup" actual means? > 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. True, there is an exception-penalty. I wouldn't assume more then 5-10%, but I might be wrong. It would be actual great to get some performance-messurements for SjLj vs DW2, as I assume there is a lot of rumor and wrong assumptions on this subject. > - DW2 potentially generates bigger libraries. The overhead however is not > big (< 10%) for typical applications. Sure, code gets bigger due unwind-tables which are produced. You have to generate for all code you want to throw over such tables. So don't miss to build your C-code with exception-enabled, if you want to throw within, or over that code. > - 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). Yes, actual this is the reason why we prefer for 32-bit SjLj over DW2. > - following from the above, one should never mix code compiled with DW2, > and code compiled with SJLJ, in one project. Right, it is no good idea to mix both exception-mechansims if both are using shared libraries of gcc (libgcc, libstdc++, etc). As long as the TUs are isolated and no shared-library conflicts are there, it might work. > - mingw.org has switched to DW2 since a while. Right, they are using it by default. > - 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. For x64 there is no DW2 support. So I would strictly recomment to switch to 4.8 gcc version ASAP. The 32-bit version doesn't have SEH support due the latent Borland-patent issue about stack-based exception handling. > Anything I missed? No, think you listed all important points pretty well. Only thing I might want to add about dw2 for 32-bit is that gcc's code for it is a bit fraguile due used function-byte-code-patterns in this unwind handler. So I am not very much convinced about dw2 stability in general. but that's more a personal impresseion and not a strong point. > Thanks > > Kai Cheers, Kai ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
