Consider using DwarFS

[probonopd]

https://github.com/mhx/dwarfs is making bold claims:

So in this comparison, mkdwarfs is more than 6 times faster than mksquashfs, both in terms of CPU time and wall clock time. In terms of compression ratio, the DwarFS file system is more than 10 times smaller than the SquashFS file system.

It'd be interesting to do some real-world comparisons by recompressing existing AppImages in DwarFS.

Reference:

• https://github.com/Phantop/appdwarf

[FryingPanBrock]

I have done some informal tests on some AppImages I have lying around. MB are megabytes, not mebibytes.

Cryptomator AppImage: 59.6 MB, 5.5 s AppDwarf: 48.4 MB (19% smaller), 4.3 s (22% faster)

FontForge AppImage: 42 MB, 1 s AppDwarf: 31.2 MB (26% smaller), 1 s (same)

Inkscape AppImage: 126.7 MB, 3.5 s AppDwarf: 82.2 MB (35% smaller), 3.4 s (3% faster)

LibreOffice AppImage: 270.1 MB, 4.1 s AppDwarf: 206.3 MB (24% smaller), 3.2 s (22% faster)

qView AppImage: 44.2 MB, 0.7 s AppDwarf: 32.3 MB (27% smaller), 0.6 s (14% faster)

VSCodium AppImage: 124.6 MB, 1.9 s AppDwarf: 91.2 MB (27% smaller), 1.8 s (5% faster)

In the median case, the DwarFS image is 27% smaller and loads 10% faster. AppDwarf creates an .sh file which you cannot simply mark as executable and launch from Nautilus. Furthermore, installing DwarFS requires manually adding it to PATH. However, if DwarFS were used in AppImage, I assume you could solve these issues. Switching from SquashFS to DwarFS is a no-brainer which improves the AppImage format without drawbacks.

[probonopd]

Thanks for your tests @FryingPanBrock. Interesting!

It would be valuable to do very systematic testing using the various zstandard compression levels and block sizes vs. DwarfFS, and then consider app size, app launch speed, zsync efficiency for AppImageUpdate, and (not so important) filesystem creation time.

Definitely something to be looked into. Maybe these tests could be scripted, unfortunately I don't have the time to do so now.