Excessive exception size cost ...

[Michael Meeks]

Hi there,

	First - thanks for spending the time to generate some new data to look
at :-) it's really interesting:

On Tue, 2012-03-27 at 12:53 +0100, Caolán McNamara wrote:
> 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

	Interesting. The 64-bit-ness leaves the exception unwind tables almost
the same size, while the code increases in size:

 code             74126kb    # ia32
 code            140465kb    # ia64
Total: 170285850 bytes       # ia32
Total: 358418576 bytes       # ia64

	Which is frankly staggering :-) an extra byte-prefix in front of each
64bit instruction and a few longer constants really does that ? ;-) that
the %age of the overall size ~40% doesn't increase is further testimony
to other substantial size increases; I assume you're compiling -Os ? (if
so, it's another nail in the x86_64 story I guess).

	Usually, I'd assume compiler optimisation is a pointless / done task -
but this looks -really- bad :-) Quite possibly our most efficient path
wrt. shrinkage is to go and give hard stares to our respective compiler
guys.

> > 	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.

	Well, we force page them in as we launch LibreOffice, and then we go
throwing a handful of random non-exceptional UNO exceptions as we start
up, so ... not sure :-)

> Maybe large bits of mozilla are compiled without exceptions ?,

	It seems likely, certainly.

> > 	They provide us with very little real value since we just abort when
> > they are thrown in ~all cases.
> 
> These specific bad_alloc exceptions or all of our exceptions?,
> because trying to e.g. revert to a global -fno-exceptions world
> seems impractical.

	I guess it'd be the ripple effect of every method that throws something
no matter how small polluting it's callers. Of course, annotating all
methods carefully with the right 'nothrow' attribute is not feasible
either, but in theory LTO is able to detect and propagate that through
functions.

	Presumably exceptions are fair enough in the UNO-world where exception
throwing is done mostly for fun - before sfx2 throws all the results
away in favour of a user-reported, and translated 'General Error'
wrapper ;-) Obviously as we use UNO less for core functionality for
which it is not suited, I suggest we try to avoid using exceptions in
new code where possible, and try to avoid these highly granular
exceptions that ripple up from every trivial object allocation / string
method.

	But - beyond that, I'm still in shock over the 64bit doubling of the
code-size ;-)

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot