Consider ZStandard compression
Compressing the installer data with ZStandard could reduce the size of a full KiCad 5.99 installer from currently 1.0GB (5.9GB uncompressed) to
- 910MB (ZStd level 5, 130MB/s compression)
- 720MB (ZStd level 8, 56MB/s compression)
- 680MB (ZStd level 11, 40MB/s compression)
- 645MB (ZStd level 15, 10MB/s compression)
- 540MB (ZStd level 17, 6MB/s compression)
- 510MB (ZStd level 19, 2MB/s compression)
The highest ZStd levels (20, 21, 22) use a RAM intensive algorithm, as does 7zip. For comparison what is possible if one is willing to commit several GB of RAM for compression and several 100MB for decompression:
- 402MB (7zip LZMA2 Ultra, 2.8MB/s compression)
Measured compressing a TAR on a i7-7500U, so this is on the low end for 2021. ZStd decompression can use multiple cores and the speed (at least 300MB/s on most PCs) is independent of compression level. For nightlies, level 5-8 should be enough and still beat deflate as is used now by NSIS in compression ratio and build time. Levels 11-17 could be used to shave off another 100-200MB for release builds without any cost to the user. Fwiw, Fedora and Arch have switched their packages to ZStd last year: https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/
Of course, ZStd is not supported by NSIS, but I thought it should be noted for future reference.
One could pre-compress the bin/symbol/3dmodels/footprints selectable parts to big .tar.zstd files, embed tar/zstd.exe, build NSIS without compression and run the decompression as part of the installer - not sure if that is worth the effort.