Compression set to maximum makes AppImages run very slowly

[ashleysimpson]

trafficstars

• Electron-Builder Version: 22.13.0

• Node Version: 14.17.0

• Electron Version: 13.2.3
• Electron Type (current, beta, nightly): current

• Target: AppImage

Question/Bug Report

We started using the compression flag recently and setting it to maximum. This did decrease the package size for us, which was great. One issue is that it makes the AppImage run really slow. Not sure if this is expected or not but we were really confused for a while and had to revert this change. Just wondering if this should be something mentioned in the documentation or maybe it is an issue that should be looked into (I understand that AppImages are self-contained and therefore any form of compression might affect the speed). Thanks! Really appreciate all the work that is put into this package.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Nantris]

@mmaietta could we re-open this? I did some poking around but I can't figure out why it makes AppImage so slow.

[mmaietta]

Happy to do so.

Compression setting is applied here: https://github.com/electron-userland/electron-builder/blob/b23a9b69ff2138be0ccb60f6454d654771e2da4f/packages/app-builder-lib/src/targets/AppImageTarget.ts#L90-L92

Compression is passed to app-builder-bin https://github.com/develar/app-builder

I'm not sure what compressions are supported though. Based off previous issues with app-builder during an upgrade (and subsequent revert https://github.com/electron-userland/electron-builder/issues/6678) Might be?

xz, zlib, zstd

[Nantris]

Ah I see. I always figured it was like the settings for a zip, maximum, normal, store, etc.

I did a very quick look into app-builder-bin and the issues and the only thing I found was this comment that mentions a configurable compression level for zstd - which iirc is the default for normal compression in electron-builder. Is electron-builder already passing a number between 1 and 22 for the compression level? (The default being 15) - If not, that might be an alternative for implementing "maximum" compression - although since it's not really maximum, maybe it would be better to add an intermediary option like "more" and update the docs to mention that maximum can reduce size a lot for macOS/Linux, at the expense of startup time?

[ArtemAvramenko]

I can't imagine a case where xz compression would be acceptable for an Electron.js app around 100 MB in size.

When compression is set to "maximum" any other algorithm (lzo, lz4 or zstd) should be used. Let there be a slightly larger output size. In any case, it's better than the "normal" compression we have to use at the moment.

[Nantris]

I think the compression algorithms are beyond the scope of this library and it's just leveraging what's available on the underlying app-builder-bin. I agree though. If you file an image on that repo definitely crosslink it here.

[ArtemAvramenko]

@Slapbox Thanks, I finally understood your suggestion and figured out how these libraries work together. That is, first we need app-builder to be able to pass the -Xcompression-level parameter. And only then would electron-builder potentially be able to pass the compression level for zstd.

[ArtemAvramenko]

It would be great if someone could compare the compression ratio on a simple Electron app with two sets of options:

-comp xz -Xdict-size 100% -b 1048576

-comp zstd -Xcompression-level 22

My knowledge of Linux and SquashFS is unfortunately not at the level to figure this out quickly.

It may suddenly turn out that with maximum compression zstd will outperform xz.