Is it OK to use the Boost C++ library for a mobile project where binary size matters? I don’t think so.
A few days ago I noticed that some of the object files generated for my C++ iOS project were quite large – over 1 megabyte. They were the ones that used some parts of the Boost library. I decided to get rid of Boost to see if it would have any effect on the size of the resulting binary.
I started replacing various parts of Boost. The new code wasn’t any more complicated, the number of lines remained roughly the same and I didn’t have to do any major refactoring. From the very beginning, it became very clear that Boost was bloating the binary a LOT.
In the following table, you can see what part of Boost I got rid of and how much it reduced the size of the entire app bundle, compiled for the iOS simulator in Debug mode, with Xcode 4.3 and Clang 3.0. This is what I kept looking at as a rough indicator as I was going along.
|Got rid of about 40 calls to boost::format, replaced with snprintf||10.2 MB||9.7 MB|
|String utilities – tokenizer used in three places, string trim twice, replaced with strtok||9.7 MB||9.5 MB|
|Removed a few of the lexical_casts used throughout the code||9.5 MB||9.4 MB|
|Removed 2 out of 5 cases where property_tree was used to load some xml||9.4 MB||9.2 MB|
|Removed use of boost::random||no significant change|
|Removed use of boost::signals2 (replaced with Sarah Thompson’s SigSlot)||9.2 MB||5.9 MB|
|Removed remaining 3 uses of property_tree xml loading (replaced with rapidxml)||5.9 MB||5.3 MB|
Nice. But wasn’t a lot of that made up by debug symbols? What about standalone optimized ARM binaries?
|Optimized ARM binary with Boost||1.2 MB|
|Optimized ARM binary without Boost||392 KB|
Hm, looks pretty much the same. Big savings.
Compilation time has improved significantly as well. My rough estimate is that a full build is now 6x faster (Yes!!! Six times faster!!! Nine exclamation marks!!!) I was using precompiled headers for the entire time.
So that’s that. No more Boost in my games.