Speed up AppImage execution by running pre-extracted/mounted filesystems

[iTrooz]

Pre-submit checks

• [X] I checked for similar issues beforehand, but could not find any. I could not add my proposal to any existing issue.
• [X] I am going to take the time to to fill in all the required details. I know that the bug report will be dismissed otherwise.

Feature description

some AppImages take a long take for me to start up. I'd like them to be faster

Proposed solution

Extract or mount Appimages at some point before running them.

Here are some tests I conducted with Joplin-2.14.17.AppImage (236MiB) (I stop the timing when the image in the default note loads) Normal AppImage run: 12.9s 12.4s 12.5s With appimage-mount done before: 8.5s 8.3s 8.5s With appimage-extract done before: 8.3s 8.3 8.2s

Here are the ways I think we could improve startup time, and their problems:

• premount all AppImages on integration/system startup
  • What implication does this have ? Maybe will consumes memory or CPU in background ?
• extract AppImages in a folder on integration
  • This will take a lot of disk space. There should be an option to enable/disable that
• Scan all folders for an AppRun in the AppImage folder (so that users can manually extract AppImage there, and they will still be integrated)
  • I don't see any downside in this, but it could be combined with other options

Alternative solutions you considered

idk

Additional context

No response

[Samueru-sama]

You might wanna read this:

https://github.com/AppImage/AppImageKit/issues/478#issuecomment-1944449840

This is mostly an issue with appimagetool setting to compression too high.

[iTrooz]

Thanks ! hope this get resolved. I can help if needed

[Samueru-sama]

Thanks ! hope this get resolved. I can help if needed

Well in that case it would be changing the default compression level and block size that appimagetool uses to zstd level 1 and whatever block size mksquashfs uses by default.

[TheAssassin]

I don't think that this is something I'd want to implement with AppImageLauncher. AppImageLauncher holds up the key principle of AppImages being a single, (mostlly) self-contained file.

Regarding performance issues with compression settings, let's fix that at the root of the problem. @Samueru-sama linked the right issue already.

[Samueru-sama]

Note with https://github.com/AppImage/appimagetool/pull/65 the issue I was talking about was fixed.

There is this other remaining issue: https://github.com/AppImage/type2-runtime/issues/116 which would help a bit as well.