[xsd-users] Unexplained code size increase

Boris Kolpackov boris at codesynthesis.com
Tue Apr 24 17:13:24 EDT 2007


Hi Glenn,

Glenn Nieuwenhuyse <glenn.nieuwenhuyse at gmail.com> writes:

> For merely 10 small classes ~50KB of stripped binary code (.text section)
> seems huge.

Thanks for a nice test case. Some time ago we did extensive code
analysis and optimization which resulted in significant space
reduction. We used nm to dump and analyze the size of each symbol
in the resulting object code. I tried the same techniques on your
example.

To make sure we compare apples to apples, I commented out everything
in test.cpp so that main() is an empty function. Then, with the help
of nm (command: nm -C -S --size-sort -r d Large.o), I got a list
of things that end up in the object file for each bitfieldN type:

0000000000000000 0000000000000011 V typeinfo name for bitfield1
0000000000000000 0000000000000024 V typeinfo for bitfield1
0000000000001344 0000000000000040 B bitfield1::txt::default_value_
0000000000001280 0000000000000040 B bitfield1::type::default_value_
0000000000000000 0000000000000040 V vtable for bitfield1
0000000000000000 0000000000000112 W bitfield1::~bitfield1()
0000000000009888 0000000000000115 T bitfield1::_clone(xsd::cxx::tree::flags, xsd::cxx::tree::_type*) const
0000000000000000 0000000000000126 W bitfield1::~bitfield1()
0000000000010208 0000000000000184 T bitfield1::bitfield1(bitfield_1 const&, xsd::cxx::tree::string<char, xsd::cxx::tree::simple_type<xsd::cxx::tree::_type> > const&, type_attr_type const&)
0000000000009696 0000000000000184 T bitfield1::bitfield1(bitfield1 const&, xsd::cxx::tree::flags, xsd::cxx::tree::_type*)
0000000000010400 0000000000000184 T bitfield1::bitfield1(bitfield_1 const&, xsd::cxx::tree::string<char, xsd::cxx::tree::simple_type<xsd::cxx::tree::_type> > const&, type_attr_type const&)
0000000000010016 0000000000000184 T bitfield1::bitfield1(bitfield1 const&, xsd::cxx::tree::flags, xsd::cxx::tree::_type*)
0000000000023456 0000000000000603 T operator<<(xercesc_2_7::DOMElement&, bitfield1 const&)


The second column is the size. It adds up to 1847 bytes per type.
The strange thing here is that at the same time the size difference
between the .text section of large and small is 29648 bytes or 3294
bytes per type. I am not quite sure where this difference comes from.

Other sections that grew are .rodata, .bss, and exception handling
related sections. From this analysis it appears that optimizing the
individual functions won't make much difference.

If you have any further ideas -- let me know. I am also going to ask
on the g++ newsgroup about this.


hth,
-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070424/6adbe7b1/attachment.pgp


More information about the xsd-users mailing list