{"id":222,"date":"2009-09-20T09:23:36","date_gmt":"2009-09-20T16:23:36","guid":{"rendered":"http:\/\/gameangst.com\/?p=222"},"modified":"2009-09-20T09:25:01","modified_gmt":"2009-09-20T16:25:01","slug":"minimizing-code-bloat-static-allocations","status":"publish","type":"post","link":"http:\/\/gameangst.com\/?p=222","title":{"rendered":"Minimizing Code Bloat: Static Allocations"},"content":{"rendered":"

This article is a continuation of Minimizing Code Bloat for Faster Builds and Smaller Executables<\/a>.<\/em><\/p>\n

Static allocations are certainly the simplest and most predictable sources of code bloat. \u00a0Static allocations refer to data structures in a program for which storage is allocated for the entire duration of the application’s execution. \u00a0 In C++ file, class, and local static variables all require static allocations. \u00a0Additional examples of static allocations in C++ are global variables, string literals, and virtual function tables.<\/p>\n

Static allocations can be very useful in some circumstances, but they can also be very wasteful. \u00a0Most of the code in an engine is executed very infrequently, which means most of the static allocations supporting that code are rarely needed. \u00a0Unfortunately since static allocations exist for the lifetime of the program, they’re taking up memory whether you’re using them or not.<\/p>\n

In addition to possibly wasting memory, static allocations can increase program link and load times. \u00a0The memory for most static allocations is reserved directly within the application binary. \u00a0Consequently, every megabyte of static allocation is a megabyte that must be written to disk every time you link, copied across the network every time you deploy, and read from disk every time you launch.<\/p>\n

The one exception to this is a special kind of static allocation known as bss<\/a> data. \u00a0Static allocations that are known at compile time to be zero-initialized are placed in a special section of the executable called the bss section. \u00a0Memory used by objects in the bss section isn’t reserved in the executable, instead it is allocated by the program loader. \u00a0Bss data doesn’t significantly impact build times, but it has the same run time memory requirements as other static allocations.<\/p>\n

In the list of code bloat causes, static allocations are usually a very distant third, but every engine I’ve investigated for static allocations has yielded a few unpleasant surprises.<\/p>\n

Dumpbin isn’t of much help when it comes to tracking static allocations. \u00a0Data symbols aren’t packaged as COMDATs, so they don’t show up in the \/headers<\/em> report I’m so fond of. \u00a0 To gather statistics on the static allocations within your application, you’ll have to crack open the PDB. \u00a0Every static and global variable is documented in the program database along with its size and, through some creative cross-referencing, its source file.<\/p>\n

Large static objects are easy to find–just sort the data symbols by size and gawk at the top offenders. Don’t stop there though. \u00a0If you generate a lot of code with templates or macros, you may have large numbers of relatively small static objects. \u00a0To quantify the cost of these objects you’ll need to do some pattern matching on symbol names. You can strip template parameters from symbols so MyClass<int>::s_buffer<\/em> and MyClass<float>::s_buffer<\/em> get counted together in the stats, or you can strip away the scope entirely and tally the stats for all statics named s_buffer<\/em> together.\u00a0 I find it useful to analyze the results from collapsing symbol names in a variety of different ways. \u00a0Which option yields the best results depends on the particular codebase I’m dealing with and the type of code generation it uses.<\/p>\n

That covers it for static allocations and for executable size optimizations in general. \u00a0I still have a couple topics to go, but from now on they’re relevant to build times alone. \u00a0Coming up, incorrect inlining<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

This article is a continuation of Minimizing Code Bloat for Faster Builds and Smaller Executables. Static allocations are certainly the simplest and most predictable sources of code bloat. \u00a0Static allocations refer to data structures in a program for which storage is allocated for the entire duration of the application’s execution. \u00a0 In C++ file, class, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[8,14,7],"_links":{"self":[{"href":"http:\/\/gameangst.com\/index.php?rest_route=\/wp\/v2\/posts\/222"}],"collection":[{"href":"http:\/\/gameangst.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/gameangst.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/gameangst.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/gameangst.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=222"}],"version-history":[{"count":15,"href":"http:\/\/gameangst.com\/index.php?rest_route=\/wp\/v2\/posts\/222\/revisions"}],"predecessor-version":[{"id":313,"href":"http:\/\/gameangst.com\/index.php?rest_route=\/wp\/v2\/posts\/222\/revisions\/313"}],"wp:attachment":[{"href":"http:\/\/gameangst.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/gameangst.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=222"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/gameangst.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}