Re: Excessive exception size cost ...

On 03/08/2012 06:05 PM, Michael Meeks wrote:
>         So - there is the 1.9% size saving ~3.3Mb saved (which is a lower bound
> - we can do better by being more complete).

Yes, exceptions do come at a cost (in object size).  As I already said, 
if people consider this cost substantial in the case of std::bad_alloc 
thrown from the rtl::O[U]String inline functions, we could change those 
inline functions to use std::abort instead (with the rationale that 
these OOM conditions are currently not handled anywhere, anyway).

>         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 code; that is cf.
>
> http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/scripts/relocstat.pl#n547
>
>         from just two section types: .gcc_except_table and .eh_frame.
>
>         It appears that for every 10 bytes of .text (ie. code) we create 6+
> bytes of exception unwind information.

The relative numbers are smaller for x86_64, btw.  ;)

>         Given that we then that in (100 - epsilon)% of the generated cases
> don't do anything at all useful with the results beyond the crash
> handler, this seems rather a high cost to pay.

So, how large is epsilon in practice?  In other words, which percentage 
of code locations through which any kind of exception can pass can be 
shown to only ever be passed by exceptions that are not handled (and 
thus lead to abort)?  Do you have any actual numbers?

>         We can also see that of the two potential causes of bloat removal of
> not doing this:
>
>         a) not in-lining:

Sorry, my parser broke down on the above lines.

[...]

>         So - there we are: exceptions hurt, they hurt really a lot size-wise,
> and they provide us with very little real value since we just abort when
> they are thrown in ~all cases.

Again, what makes you claim that almost all exceptions thrown in the LO 
code base are left unhandled?

Stephan