FW: FW: Huge binaries

[Hite, Christopher]

I've traced down an area where the debug info seems to be growing more
quadratically to what one would expect (see N in code).  It uses some
boost header only libraries, which I'm not sure I can reasonably
recreate.

//------------------------------------------------
// code
#include <boost/mpl/range_c.hpp>
#include <boost/mpl/transform.hpp>
#include <boost/mpl/copy.hpp>
#include <boost/mpl/list.hpp>
#include <boost/mpl/front_inserter.hpp>
#include <boost/mpl/for_each.hpp>

#include <boost/fusion/include/map.hpp>
#include <boost/fusion/include/at_key.hpp> #include
<boost/fusion/include/as_map.hpp> #include
<boost/fusion/include/mpl.hpp>

const unsigned N=10;
// 50 is realistic for my program
// debug info grows > quadratically ; N=40 creates ~100MB of debug info

typedef boost::mpl::range_c<int,0,N> IntRange;

typedef boost::mpl::copy<
	IntRange,
	boost::mpl::front_inserter< boost::mpl::list0<> >
>::type                               IntList;


struct Int2FusionPair{
	template<typename Int>
	struct apply{
		typedef boost::fusion::pair<Int, double> type;
	};
};

typedef typename boost::mpl::transform<IntList,Int2FusionPair>
	::type FusionPairList;

typedef typename boost::fusion::result_of::as_map<FusionPairList>
	::type FusionMap;



struct Initer{
	template< typename U > void operator()(U x)
	{
		boost::fusion::at_key< U >(fm) = U::value * 0.01;
	}

	Initer(FusionMap& fm_): fm(fm_) {}

	FusionMap& fm;
};

void init(FusionMap& fm){
	boost::mpl::for_each<IntRange>(Initer(fm));
}


int main(){
	FusionMap fm;
	init(fm);
	return 0;
}

//------------------------------------------------
To compile:

g++  -ftemplate-depth-256 -O0 -fno-inline -Wall -g -pthread  \
 -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS  \
 -DBOOST_MPL_LIMIT_LIST_SIZE=50 -DBOOST_MPL_LIMIT_MAP_SIZE=50 \
 -DFUSION_MAX_MAP_SIZE=50 -DFUSION_MAX_VECTOR_SIZE=50  \
 -I"/fs/tools/L2/boost_1_43_0" big_db_file.cpp

g++ (GCC) 4.5.2 .   You mentioned things might get better with 4.6.  Was
that only because multiple copies of debug info are removed or will it
also help a single module like this?
g++ (GCC) 4.6.0     A improvement in size for debug builds, barely any
for release builds with debug info.


Chris


-----Original Message-----
From: Ian Lance Taylor [mailto:iant@google.com]
Sent: Wednesday, February 23, 2011 1:41 PM
To: Hite, Christopher
Cc: gcc-help@gcc.gnu.org; bill@rkirkpat.net
Subject: Re: FW: Huge binaries

"Hite, Christopher" <Christopher.Hite@partner.commerzbank.com> writes:

> If I lock the process into memory is does it lock the debug info into 
> memory too?

No.

> Perhaps I can run a stripped binary in production and then analize 
> it's cores with the unstripped version.  Will that work?

Yes.

But be aware that the debug info costs you nothing at runtime.  The only
cost is the disk space that it occupies and the bandwidth required to
transmit the extra data when copying the binary between machines.

Ian