On Wed, 2012-02-29 at 08:42 +0100, Stephan Bergmann wrote:
> But how bad is that, anyway? A little experiment shows that the
> compiler will happily outline those inline functions detecting for
> bad_alloc, creating one instance of them per library.
Heh ;-) so - I'd love to see the size difference between two identical
LibreOffice's compiled with and without those exceptions enabled - of
course, the fact that there is just one function is interesting (and
encouraging), but the required unwind tables for all these exceptions
that (in practise) never ever happen impact every single method that
uses strings, and stops us marking other methods as not throwing
exceptions (and/or detecting that during LTO as/when we get there).
Presumably since LTO does a lot of this manual propagation of real (as
opposed to annotated) exception throwing state, until we start doing
that aggressively in libmerged we won't really be able to get a good
idea of the real cost.
Last I did the analysis (which was some years back) exception data is
>10% of stripped binary code size - which is at least significant -
particularly if it is substantially unused ;-)
Having said all this - I think we can agree that if we are calling this
new 'createFromAscii_WithLength' method - which is (currently) only
called during these magic constructors for compile time constants, that
the chance of having a 4Gb compile-time constant string in the source is
somewhat minimal ;-) and that there is certainly no need to throw an
exception and bloat the call-sites for this case at least.
All the best,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
