[Development] Disabling exception support in QtCore?

[Thiago Macieira]

On quarta-feira, 2 de outubro de 2013 20:39:25, André Pönitz wrote:
> Size overhead for "just enabling exceptions" is (of course depending on
> actual model/implementation) typically cited as 5-10%, which incidentally
> matches Thiago's findings for Qt Core rather well. That's a pretty high
> price for a single feature in general, and especially so if it does not add
> adequate value. In my book removing the need to pay for features one
> doesn't use is a Good Thing more often than not.

Here's an interesting thought:

What if the compiler would not intersperse the exception handler code with 
normal code? Right now, each generated function contains all the exceptional 
code paths from all cases, including inlined functions. If you read the 
disassembly of any C++ library, you'll see something like:

function1:
  prologue
  body of the function
  epilogue (including return)
  exception code
function2:
  prologue
  body of the function
  epilogue (including return)
  exception code

That means the increase of 5-10% in code size on disk is translated a 5-10% 
increase in RAM usage too. What if all those "exception code" blocks were 
moved elsewhere?

In that case, the increase on disk size might not be the same as the increase 
in RAM size. The exceptional code would be paged in only in case exceptions 
did actually get thrown.

This is just a thought experiment.

To implement it, we'd need an exception format that allowed two or more 
separate bodies for a function, a compiler option or pragma to tell the 
compiler that exceptions are unlikely, and a linker that cooperates.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131002/924281a8/attachment.sig>