So far, we have brought faster compression algorithms, and have brought multi thread compression. Users can feel faster installation speed only when a faster compression algorithm is used, however, we may have to choose slower compression algorithms like lzma for better compression ratio. In this case, the prepare speed is indeed improved while the installation speed is as slow as usual. We should also improve this!

according the 7z sdk, http://www.7-zip.org/sdk.html. the decompression speed is about 20MBps to 30MBps in 2Gbhz CPU, it’s slower than traditional hard disk read/write speed which is about 120MBps(SSD is about 250MBps to 450MBps). At the mean time, 4 threads(Intel i5) and 8 threads(Intel i7) are very popular. According this, we can accelerate the speed to be about 4x or 8x faster!

Due to the scripting nature of nsis, I don’t want to significantly change the logic of installation, so only improve decompression speed of large files(more than one chunk). By default, the filebuf is 4MB. We split files into chunks according compression thread number and filebuf size.

Case 1: we have a 1MB file, it’s compressed in single thread and is stored into a single chunk.
Case 2: if it’s a 500MB file, and we use 8 threads for compression, then we get 8 chunks. the installer will use up to 8 threads to decompress(it use maximum thread of physical cpu, so it could be 2 threads if it’s running on a dual core cpu).
The compression thread number and decompression thread number are both configurable.

Here is part of installation log of 16 threads(still contains 6.9GB data, using lzma):

is it possible you provide your modification to the main developper of the NSIS project so they can review it and include it in the future realease so everyone can benefit from what seems a wonderful improvement ?