AppImage: Speed boost when AppImages are pre-extracted then invoked → Therefore make a wrapper script to automate this

[luzpaz]

Apparently AppImages run faster when they are first extracted:
./FreeCAD.AppImage --appimage-extract

See thread on reddit which contains a batch script to automate this: https://www.reddit.com/r/FreeCAD/comments/1fv69g2/breaking_out_the_appimage_for_faster_response/lqc8l5r/

[adrianinsaval]

appimages are compressed so there is some overhead in accessing the files, this is expected. How much this impacts performance depends on your hardware but I don't think it's a big difference in most cases, I would advise to document this in the wiki and it leave it at that.

[CIKoolK]

If anyone is interested I have created a v2.01 of my script that:

1. Opens a File Manager dialog to select the .AppImage file to be extracted;
2. Extracts sane to a folder in the same folder as the AppImage input file named the sane as the images base filename (I.e. MyApplication.AppImage would be extracted to folder ./MyApplication);
3. Optionally can delete the input file (not recommended unless it's just a working copy)--it asks twice for confirmation;
4. Optionally creates a homepage .desktop launcher (Ex: ~./MyApplication,desktop), displaying the icon found in the AppImage archive;
5. Optionally launches the extracted application;
6. Displays the fully qualified launch command and if created the name of the shortcut;

Note: this works with any .AppImage package, not just FreeCAD...

Give me a "Yell" if interested: [email protected]

[luzpaz]

@CIKoolK Yes, we're interested! And we'd like to add to our documentation

[oursland]

It's been reported that the default gzip compressor in AppImages is the culprit and the vast majority of the performance penalty can be avoided by switching to the zstd compressor.

[adrianinsaval]

last time I checked appimagetool didn't support zstd but I could be wrong, plus appimage documentation is sometimes awfully outdated so it wouldn't surprise me if it actually works

I'm totally wrong and don't know why I thought that, it seems appimagetool uses zstd by default nowadays, we can play around with the compression level but it will always be a tradeoff between file size and performance

[CIKoolK]

May indeed be so, however how does that help the end-user?

[CIKoolK]

Exactly; It really doesn't matter what compression algorithm is used, for any given system extracting the files and executing directly will always be faster--it has to be...

[adrianinsaval]

well we were actually still using gzip because for whatever reason the appimage devs decided to move where they made their releases so we where using a 1y+ old build instead of the latest, and I had forgotten to update the url in the github action (I had updated it for cirrus before!). A new bundle is being created now with zstd compression, could you test the difference in performance?

Exactly; It really doesn't matter what compression algorithm is used, for any given system extracting the files and executing directly will always be faster--it has to be...

I don't think that's entirely true, in some situations reading compressed data can actually be faster (fast cpu + slow hdd + fast decompression algorithm) and in many cases the performance impact can be very low.

[adrianinsaval]

new bundle is up, and as a side benefit it is actually 76mb smaller, nice tip @oursland thanks. I am unsure how to reliably test the performance impact of this

[oursland]

I don't think that's entirely true, in some situations reading compressed data can actually be faster (fast cpu + slow hdd + fast decompression algorithm) and in many cases the performance impact can be very low.

Indeed. It is often the case that decompression is faster than raw media access. Many compression systems have been designed to be slow during compression and very fast during decompression. zstd is one such example, and it typically outperforms the compression ratio of gzip.

[adrianinsaval]

on my pc I could not measure any meaningful difference in startup time with gzip vs sztd, they both took around 3.3-3.6s and extracted it took 2.4-2.5s I personally wouldn't give up the convenience of the appimage for such a small gain but if you have a slow cpu it could be worth it. This is what I ran:

time ./FreeCAD.AppImage --safe-mode close.FCMacro

close.FCMacro just had

Gui.runCommand('Std_Quit',0)

surely there's much better ways to test performance but this was easy to do ;)

Anyways, I don't see any further action that we should take here, ok to close this? Of course I'm always open to suggestions

[oursland]

The user SamualSmash on reddit has a startup timing script that was used to determine the time delta between gzip, zstd, and decompressed. I have requested that they perform a comparison with the new weekly release.

[adrianinsaval]

oh there's one extra benefit of having updated appimagetool which I was also investigating why it wasn't working, it now uses the newer appimage statically linked runtime so it no longer needs libfuse2 installed on the system.

[CIKoolK]

I find that the newly created bundle no longer produces verbose output upon executing appimage-extract...

Also and FWIW, I find extracting the contents of .AppImage archives to be well worth the small one time investment and find they all run more smoothly as well as launching faster--UVTools is quite noticeably smoother. As with most everything YMMV...

[oursland]

/u/SamuelSmith did a bit of a benchmark with the updated AppImage.

Compression	Time
gzip	7.092 s
zstd	5.183 s
none	2.259 s
rebuild zstd	3.721 s

The rebuild zstd configuration was created by running: appimagetool --comp zstd --mksquashfs-opt -Xcompression-level --mksquashfs-opt 22 ./squashfs-root

[CIKoolK]

Are those the bundled application launch speeds?

[oursland]

Yes. I have just added the optimization commands used by /u/SamuelSmith and re-generated the weekly builds. The weekly builds should now match his startup time.

[adrianinsaval]

can you share the benchmak script? for pure curiosity I'll be interested on testing the effects on aarch64 and ssd vs hdd

[oursland]

I don't possess the benchmark script. It was described in this comment.