Excessive exception size cost ...
Caolán McNamara
caolanm at redhat.com
Tue Mar 27 04:53:46 PDT 2012
On Thu, 2012-03-08 at 17:05 +0000, Michael Meeks wrote:
> So - because of the expert skepticism of my estimate of where the
> wasteage is: ie. exception unwind tables, I re-ran my relocstats.pl tool
> (which I've checked in here):
So, here's my numbers.
Firstly x86_64 product-mode, no symbols, code-as-it-is-in-master
code 140465kb - 40%
exceptions 49501kb - 14%
Total: 358418576 bytes
Then with relocstat-no-inline.patch applied to add additional
rtl_string2UString_throw vs rtl_string2UString etc entry points in order
to extract the "if (pData == 0) throw bad_alloc;" out from the inline
OUString constructors and into standalone functions which are allowed to
throw.
code 140273kb - 40%
exceptions 49485kb - 14%
Total: 358116559 bytes
So, a total reduction in size of 294k bytes with that patch applied.
a 192k reduction in code-section-size
Then with relocstat.no-throws.patch applied instead to simply delete the
std::bad_alloc throws
code 139542kb - 40%
exceptions 48011kb - 14%
Total: 356163070 bytes
which makes a far more hefty 2000k over-all reduction with that patch
applied instead. A 923k reduction in code-section-size.
> Perhaps what is more frightening, is the sheer weight of the exception
> information: we have fourty-eight (48) Mb of exception unwind
> information vs. 75Mb of cod
They are frighteningly huge alright. On the other hand, presumably those
sections aren't loaded unless an exception actually gets thrown (?) so
does their presence matter performance-wise.
> It is also a markedly higher proportion than mozilla:
Maybe large bits of mozilla are compiled without exceptions ?,
historically at least given https://developer.mozilla.org/en/C
++_Portability_Guide#Don%27t_use_exceptions exceptions seems to have
been avoided.
> We can also see that of the two potential causes of bloat removal of
> not doing this:
>
> a) not in-lining:
>
> if (error_return) throw ::std::bad_alloc();
More information about the LibreOffice
mailing list