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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development