Hi guys,
On Wed, 2012-02-29 at 16:29 +0000, Michael Meeks wrote:
So - I did some more analysis, and re-compiled all of LibreOffice both
with and without the attached patch - analysing all 287 shared libraries
we get:
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):
http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/scripts/
over the code both with and without those extra bad_alloc exceptions we
spit out on every string allocation (which are used to do nothing more
useful than abort ;-).
Here are the numbers from:
$ relocstat.pl --data-profile *.so # in program/
Section size breakdown # with no string exceptions
code 74126kb - 45%
exceptions 46003kb - 28%
data 20913kb - 13%
linking 15432kb - 9.3%
data relocs 8462kb - 5.1%
...
Total: 170285850 bytes
Section size breakdown # with string exceptions thrown everywhere
code 75233kb - 44%
exceptions 48131kb - 28%
data 20913kb - 12%
linking 15445kb - 9.1%
data relocs 8462kb - 5%
...
Total: 173612058 bytes
So - there is the 1.9% size saving ~3.3Mb saved (which is a lower bound
- we can do better by being more complete).
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.
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.
It is also a markedly higher proportion than mozilla:
Section size breakdown
code 15923kb - 60%
exceptions 4870kb - 18%
data 3226kb - 12%
data relocs 1682kb - 6.3%
linking 460kb - 1.7%
...
This is compiled with openSUSE 12.1's default: gcc 4.6.2, and operating
on stripped binaries.
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();
vs.
b) not generating huge unwind tables for methods doing pure
string operations
The win breaks down thus:
code change: -1107kb
exception change -2128kb
So 2/3rds of the reduction is simply shrinking the unwind tables.
While it shouldn't affect the ultimate numbers, I am using the
--enable-merged-libs feature here (as is obvious from the
autogen.lastrun I posted).
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. Alternatively, perhaps they are truly a
productivity tool - they certainly let us generate more bytes of output
more quickly ;-)
Feedback appreciated, my relocstat.pl tool is untouched for several
years, possibly it is not adding up right - please do check it out.
ATB,
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Context
Exception cost on string allocations ... · Michael Meeks
Re: Excessive exception size cost ... · Caolán McNamara
Re: Excessive exception size cost ... · Michael Meeks
Re: Excessive exception size cost ... · Noel Grandin
Re: Excessive exception size cost ... · Caolán McNamara
Re: Excessive exception size cost ... · Stephan Bergmann
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.