block size 16384 for XZ makes compression pointless

[develar]

trafficstars

If user decided to use XZ compression instead of default gzip — he really wants small size of AppImage. Using 16384 as a block size makes XZ compression like gzip — for example, for Electron App 51.9 vs 50.4.

So, electron-builder now uses 1048576 instead of 16384. Size difference — 50.4 vs 39.1. 11.3 MB difference. Slow start-up time? Well, it is your choice to use XZ.

I am not going to convince you to change this setting in the AppImageTool, JFYI.

[probonopd]

@develar we are open to discussing the defaults, but the current defaults (gzip) are what proved to be best in our test of various apps (including LibreOffice) some time ago. I have not experimented much with the block size of XZ since XZ is not the default due the noticely slower application startup times.

Could it be that we are seeing effects of the asar compression in Electron builds? It is probably not helpful for size nor speed to compress files in an asar and then compress the asar in a squashfs file. Is there a possibility to ship the contents of the asar uncompressed?

[develar]

slower application startup times.

Yes, it is a reason why electron-builder doesn't use XZ by default. My point is — if user decided to use XZ, current very small block size leads to strange results (final size ~= ZIP size). The same situation if you will use ZSTD stream API incorrectly (for ZSTD minimal required buffer size = 1MB (better 32MB), in case of squashfs we cannot experiment — 1MB it is maximum).

a possibility to ship the contents of the asar uncompressed

User can, but it will be never default for electron-builder. Problem — if you use normal OS (macOS or Linux), you don't need to use ASAR, but still you have to provide windows version of app. And on Windows you should use ASAR. So, if different settings (asar true on win and false otherwise) will be applied, it will lead to situation when on release day you will discover that your app doesn't work well on Windows (because ASAR has some limitations and pitfalls). And it is not acceptable.

[probonopd]

So, if different settings (asar true on win and false otherwise) will be applied, it will lead to situation when on release day you will discover that your app doesn't work well on Windows (because ASAR has some limitations and pitfalls). And it is not acceptable.

Interesting, I understand. Thanks for the explanation.