Slides: Executable Bloat

I recently game a presentation at DICE about bloat in our game executables and how you can fight it. I’ve attached the slides to this post and they will also be up on the DICE publications site later.

Download the slides here (PDF)

Advertisements

8 thoughts on “Slides: Executable Bloat

  1. Thanks for sharing your insights – a view on code I haven’t thought about before.

    To put some of the byte-sized bloat into a better perspective to better grasp their full effect:
    – How big is the typical console game binary?
    – How much of this size is because of vtbl and the other overheads you show?

    Is the second example on slide “Avoid repetition” really a win? What is the win – there are still as many RegisterFunc calls as before but now there is also additional data segment necessary? Or does the code just makes explicit what the compiler is doing behind our backs for the first code-snippet?

    Cheers,
    Bjoern

    • Game executables vary a lot in size. I know games that have shipped with everything from 5 to 35 MB ELFs.

      The thing to keep in mind about the “bloat patterns” is that they are repeated hundreds or even thousands of times across the code base. Some game engines have over 512kb of virtual table data.

      It’s hard to extrapolate (intrapolate?) and see what the perfect size for these bloated projects would be if they had used a tighter coding style, and it’s a lot of work to try to fix it later as typically these problems are ingrained into every file of the project.

      With these things it’s easy to get into trouble, hard to get out..

  2. Nice presentation 🙂

    I have personally profiled the executable of our games in my former job so I would add this:
    Templates do take a lot of space but it is possible to get metrics from a symbols dump using nm. You can get the number of instances looking at the non-optimized executable. You need some sort of script to combines template instances together. Then you can target those that are the most instantiated by moving out code that do not depend on template types or can type cast to void * into a non-template base class or other tier. 
    To give you some metrics, we had an elf size of ~40 Mb (we obviously had bloat problem) and about 10Mb was duplicated template code. The most expensive template was a pool class. We reduced it to ~5Mb which is more acceptable. What was left was mostly stl stuff and things not worth our time optimizing. 
    We also had a lot of strings data. Look out for __FUNCTION__, __PRETTY_FUNCTION__ and __FILE__. You probably don’t need this in your release build anyway.
    Also, macros are evil. Obviously they are inlined. So there is no traces in the symbols dump. Your best guess is to do a search in file on macros that hide a lot of code. One more reason why not using macro.
    So doing these recommendations we ended up with an elf size of less than 25 Mb

    • Hi, thanks!

      Moving template code to a base class and stuff like that might work for simple cases, but stuff like templatized containers and the way they become unique by incorporating copy constructors and such really can cause a lot of bloat. IMO it would have be better if devs carefully validated their design choices before using templates everywhere 🙂

      From what I’ve heard the God of War 3 ELF was about 5.5 MB; that’s the kind of size I think all games should strive for. Compared to 25 MB that’s 20 MB more precious memory to use for animations, effects or gameplay objects — or — efficiency in terms of data layout!

      –A

      • For container templates it is possible to code specialization for Pod types using void* and size. I mean how much duplications of vector/list/etc of could there be in an entire game code or over a simple Pod struct. There is some fancy template solutions along that path. But yeah, if you have copy ctor/operator you are pretty much screwed. Then it comes down to the template user awareness to this problem. Like not using vector which is wrong on so many levels.

        We did have a rather big codebase at the time. I can’t say how it evolved but back then 25Mb was acceptable to some extent. Our older but more mature engine was between 4 and 7Mb depending on which feature we used. The new engine will probably shrink the more mature it gets too, *hopefully*.

      • also read : “Like not using vector < string > which is wrong on so many levels.”

  3. Not sure reading this when I’ve got an exam on design patterns in a week was such a good idea… 😦

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s