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@suse.com <><, Pseudo Engineer, itinerant idiot
Context
Re: String literals, ASCII vs UTF-8 · Stephan Bergmann
Re: String literals, ASCII vs UTF-8 · Lubos Lunak
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.