KDE runs build system called Craft. There you have dependencies already built according to one-size-fits-all rule because they have to fulfil needs of all KDE software. In own build system one has to build dependencies by oneself but that allows flexibility. Areas where the flexibility gave the most spectacular results have been presented below.
1) Icons
Lean BreezeIcons is packaged which weights way less than the stock one.
| — | BreezeIcons (stock) | BreezeIcons (lean) |
|---|---|---|
| size | 19,3 MB | 340 KB |
Stuff that is left out here is e.g. an Adobe icon in three different sizes.
2) HTML rendering engine
Old KHtml is packaged instead of modern QtWebEngine or slightly outdated KDEWebKit. In the table below KHtml is compared with unoptimized libraries but that’s enough to get a general feeling about the size differences.
| — | QtWebEngine | KDEWebKit | KHtml |
|---|---|---|---|
| size | 108 MB | 44 MB | 8 MB |
Looking from the security perspective, KMyMoneyNEXT renders its own HTML content and not potentially unsafe content from the web, so it should pose no threat.
3) Internationalization
ICU (and more precisely ICU data) is a third library where much has been saved.
| — | ICU data (stock) | ICU data (lean) |
|---|---|---|
| size | 25,9 MB | 5,6 MB |
Now it consists mostly from character conversion tables. It may grow if there would be support for more than English only.
4) Build flags
Compiler for KMyMoneyNEXT and its dependencies is instructed to take size as its priority - at a cost of non-optimal performance and debugging capabilities. Goal here is to showcase how far one can reduce package sizes, so it may change in the future. Here the saving is ca. 15 % on size of the package for Windows.
5) Packages compression
For distributing software, exe installer is used on Windows, dmg image on MacOS, and AppImage on Linux - just like in Craft. The difference is in their compression ratio.
Craft uses NSIS with custom 1,1 MB lzma2 decompresser to create exe installer. Built-in lzma decompress should be no worse and saves that 1,1 MB, so it has been used.
Craft uses create-dmg with the fastest gzip compression to create dmg image. It’s compatible with all MacOS versions, but the latest and packaged Qt is not. lzfse supports MacOSes that Qt supports and yields the best compression ratio, so it has been used.
Craft uses AppImageKit with the best gzip compression to create AppImage. Switching to lzma and setting larger block size yields better result. Goal here is, as before, to showcase how far one can reduce package size. This configuration noticeably lengthens application’s start-up time, so it may change in the future.
Size differences for compressed packages and after their decompression are presented in the table below.
| Build environment | Windows | MacOS | Linux | |||
|---|---|---|---|---|---|---|
| compressed | uncompressed | compressed | uncompressed | compressed | uncompressed | |
| BinaryFactory | 69,7 MB | 318,8 MB | 130,0 MB | 423,8 MB | 183,9 MB | 507,4 MB |
| TravisCI and AppVeyor (compressed as in BinaryFactory) | 23,6 MB | 94,7 MB | 39,0 MB | 99,3 MB | 38,1 MB | 107,7 MB |
| TravisCI and AppVeyor | 23,7 MB | 94,7 MB | 34,9 MB | 99,3 MB | 28,9 MB | 107,7 MB |
As one can observe, size of packages after decompression varies across OSes and is 13 % for own build system and 45 % for BinaryFactory. This should be as lowest as possible because that would mean no redundant bytes and no missing functionality across packages for different OSes. BinaryFactory’s compression ratio for exe installer is surprisingly, slightly better even with additional lzma2 decompresser.
Size gains for compressed packages relative to packages compressed as in BinaryFactory are presented in the table below.
| — | Windows | MacOS | Linux |
|---|---|---|---|
| size gain | -0,42 % | 10,51 % | 24,15 % |
As one can observe, gain is not manyfold but differences are measurable in case of MacOS and Linux.