views:

1171

answers:

5

I am working on a C++ program and the compiled object code from a single 1200-line file (which initializes a rather complex state machine) comes out to nearly a megabyte. What could be making the file so large? Is there a way I can find what takes space inside the object file?

+6  A: 

(I'm assuming you've got optimisations and dead code stripping turned on).

Turn on your linker's "generate map file" option and examine the output.

Common culprits are macros/templates that produce large amounts of code, and large global objects.

moonshadow
He's talking about an unlinked object file though.
Rob K
@Rob K, Object files are linked into a final binary. The binary has the map. Thus, the binary contains parts from the object files. You can look for functions and objects in the source file in question and see their sizes.
strager
I wish I could pick two answers.
zaratustra
+4  A: 

Possibly some template instantiations (especially the std::iostreams), and maybe extensive inlining (i.e. classes which are fully defined in a header). However, what's the problem with a 1-megabyte object file in the first place? During linking, it might very well result in a tiny binary. I got a project here with 20 MiB of object files which gets linked into a 700 KiB binary for example.

Update: Could be also some large static array/object. Besides that, with MSVC++ and GCC, you can look at the generated assembly for a file, which can give you some hints (with GCC, it's g++ -S foo.cpp, for MSVC++, it's '/FAs'). Either you will see a lot of template instances, then these are the reason. If not, it's the object size of static objects.

Anteru
+6  A: 

There can be several reasons when object files are bigger than they have to be at minimum:

  • statically including dependent libraries
  • building with debug information
  • building with profiling information
  • creating (extremely) complex data structures using templates (maybe recursive boost-structures)
  • not turning on optimizing flags while compiling (saves not that much and can cause difficulties if used too extremely)

At first I suggest to check if you're building with debug information, this causes the most bloat in my experience.

Kosi2801
A: 

Here's a macro I use to see compile time values:

template <size_t N> struct compile_time_number { private: typedef int check; };
#define compiler_check_number(N) ((compile_time_number< N >::check)0)

Then go happy at compile time to see what symbols are taking up space.

Edit: Since no one seems to understand this, I'll clarify: the way to use this is to add compiler_check_number(sizeof(<insert struct or global variable here>)). The compiler will spit out the size of the variable or struct as a compile time error. Very rarely is code the reason for a huge object file.

I use this all the time to see how big things are without having to run a debugger.

MSN

MSN
A structure's size has nothing to do with the size of an object file, unless instances of the structure are in the object file. (I did not downvote, by the way.)
strager
True, but a global or static variable of a struct that is value initialized does need to be declared somewhere in the object file, so the size of the struct does have an effect. But in that case you should use the size of the variable to begin with.MSN
MSN
A: 

Another possible reason is Link-Time Code Generation, a VC++ option. This moves the backend of the compiler into the linker. This allows for better optimizations, but the object file now has to contain all internal datastructures usually passed between front- and backend.

MSalters