Slax author's Blog (RSS)
25
August2012
Benchmark conclusions
As seen in previous post, I made some squashfs benchmarks. There are two compression formats available (gzip and lzma) and five block sizes (64k to 1m). Note I didn't consider LZO compression format, since the compression ratio of LZO is even worse than gzip.
There are three important factors to consider: speed, size and RAM usage. While the size decreases almost linearly with the increasing block size, the speed of reading doesn't improve above 512k block. RAM usage seems to be more than doubled for 1M block size, while it is rather linear with smaller block sizes, so 1M is not acceptable - 6MB for each mounted bundle means 60MB for 10 standard Slax modules, that's too much compared to 28MB while using, say, 512K block.
Now it's time to make some conclusions. To make it short, it looks like I've already decided - I'll use LZMA2 compression with 512K block size for Slax 7.
Just a reminder, if I remember that correctly, Slax 6 used 256k block size.
User comments
From my point of view, hardware does not change anything. If you have 256MB of RAM or 8GB of RAM, the RAM needed to mount one squashfs filesystem will be always the same.
Similarly, if you have faster processor then all the speeds will be much faster indeed, but if (for example) decompression of gzip fs is faster than decompression of lzma fs then it will be always faster (compared to each other), regardless of CPU used.
I did some tests, and it looks like 64MB of RAM is needed to run the kernel alone, I think minimal requirement for Slax will be 128MB (to boot into commandline). Graphical desktop (KDE) will probably need at least 256MB, it depends. I hope I will be able to tweak KDE so its RAM usage is as small as possible.
I think lzma2:128 is a better choice. using your logic 60 -> 28 mb, with lzma2:128 we use only 14 mb, ram. On 256 mb ram system I bet we can agree those extra 14 mb are going to make a world of difference. It may be more difficult to pack as much on a liveCD, but I think that lzma2:128 gives quite a benefit in ram for not a lot lost in compression (50% of ram vs 3% more storage).
On really low end systems I would even argue using the gzip because you are going to be limited in both ram and processor speed.
How hard is block size to change? I wouldn't think it would have to be a hard-coded attribute.
refering to my other posts concerning new Linux Live Kit I suggest using 512mb blocksize in conjunction with zram.
Zram will make more system ram available than the higher blocksize costs.
Sign in with Facebook
Sign in with Google
Sign in with Email
Tomas M.,
What was the hardware for those benchmarks ?
I just wonder if that picture would change in a linear fashion for hardware with different CPU for example, or there will be known minimums under which there is no point trying to use Slax 7 ? (e.g. if you have celeron ulv/600 MHz with 256MB RAM, or Atom 1.6GHz with 512MB RAM)