Blog

Compiler Bloat

Isn't it funny how programs seem to get bigger and bigger? Ask anyone involved in computing, the longer the better, how many bytes their first word processor was. Mine was WordStar 1512, coming in at 1.24MB installed. Atlantis Nova, the freeware version of Atlantis Word Processor, was fully featured and could fit on a single 3.5" HD floppy.

Programs are rarely that small these days. The (compressed) installer of LibreOffice is over 200MB. What happened?

Whilst pondering this question, I wondered how much of an influence the compiler (and associated toolkit) had on the file sizes of executables. I took a simple C++ program and compiled it in many environments to test this.

These are the release builds of exactly the same source file, compiled with default settings, 32-bit without debug symbols. The resources use about 6,500 bytes. The smallest one (40,690 bytes) is less than a third of the size of the biggest (132,608 bytes) for the same functionality. What on earth has bloated up my program so much?

For my program - security. The compiler has added lots of extra checks and graceful exits to protect against things like buffer overflows. However the size of the increase does raise an eyebrow, or at least mine. I wonder how big Microsoft Office 97 would be if it was compiled in Visual Studio 2017 today? Or what about Microsoft Office 2016 in Visual Studio 2003? (Although that would be impractical, as it is likely to be written to a newer C++ standard.)

Of course the size of the program file does not tell the whole story. It does not say how many CPU cycles will be needed, or how much RAM will be consumed. But I do wonder just how much software bloat is down to things not usually considered, rather than the obvious feature creep, and how much it costs in terms of time and energy.

Return to Blog Index