Installers and Payload Size – Part 1 of 3

Even in this day and age, download size can be relevant for software vendors hosting their own download servers.  While the difference between 12 megabytes and 15 megabytes might seem negligible to the end user, multiplied by thousands of requests this kind of bandwidth usage adds up rapidly.

There’s a few methods of reducing the size of one’s setup that we will look at today.  Some are found within InstallShield, and others are using third party tools.   It’s my hope that these will help you to get a sense of steps you can take to optimize your own setups for Web distribution.

Background Information

To get started with my testing, I picked a file format that was structured so that it would have some kind of redundancy within it to be optimized out by the Compression process.  Generally, more random, unstructured file formats compress very poorly–try it yourself, with a random file generator like ‘Dummy File Creator’.

For these tests, I grabbed a SQL Database and Transaction log I had handy from a sample AdminStudio implementation:

 

As you can see, this is a fairly decent amount of data to compress so we can see the results of different algorithms.

Compression Algorithms

Windows Installer (and by extension InstallShield) supports the same *.cab compression methods as Windows Explorer does for reading from *.cab files, which is basically MSZIP and LZX, as well as no compression at all in the *.Cab file. 

Since we’re talking about a savings in the actual container (*.cab file), I ran a quick test using the InstallShield “Batch Build” feature and then extracting the *.cab files using MSIX, and as well used 7-Zip to compress these two files with LZMA using the ‘Normal’ and ‘Ultra’ settings, just to give us a quick view of what we can expect just on the standards and containers involved.   

To be clear, Windows Installer, and by extension InstallShield, does not support LZMA compression, although LZX is supported, and belongs to the same general family of Compression algorithms.  I will get back to my reason for including this in my tests later, however.

 

These results give us about what one would expect, with the standard ZIP algorithm that most Windows Installer packages use coming in last, next to no compression at all.  This view doesn’t give us an idea about what a full project looks like, however.  So some further builds including setup.exe, and some just the regular *.msi package with an internal *.cab file are below:

 

Predictably, we’ve got a few hundred kilobytes of overhead with the *.msi package compared to its *.cab file.  What you’ll also note is that the “NoAlg” setup gets the benefits of the compression that InstallShield uses to build compress setup.exe files, using the ZLib algorithm.  ZLib in particular is what was used for setup.exe, as it was found to maintain a reasonable balance between decompression time, and reduced setup size.  Next post we'll talk about other ways to reduce your payload with other tweaks to your project file.