Very likely 25% increase in launch time due to statically linked musl

[Samueru-sama]

Issue originally discovered by @VHSgunzo here with the uruntime: VHSgunzo/uruntime#3 (comment)

Also related to this post by @Drsheppard01 here: https://github.com/orgs/AppImage/discussions/1376

Tested my extrating this appimage: https://github.com/pkgforge-dev/Cromite-AppImage/releases

Turned the AppDir into a zstd squashfs image with parameters: mksquashfs ./AppDir manual-zstd -comp zstd and then concatenated that into each respective runtime.

---

Benchmark:

• uruntime-musl takes 2 seconds on average to launch.

• uruntime-glibc takes 1.5 seconds on average to launch.

• type2-runtime takes 1.75 seconds on average to launch.

Of course this doesn't 100% mean that if the type2-runtime was compiled with statically linked glibc it would improve the launch time by 25%, but it is very likely.

For reference the uruntime-lite which is very similar to the type2-runtime is 958 KiB with static musl and 1.1 MiB with static glibc. So I think the benefits outweigh the downside of a slightly bigger runtime by a lot.

---

EDIT: Just to make it more clear, the 25% degradation happens in the uruntime when musl instead of glibc is used.

Right now the type2-runtime launch speed sits right in the middle of the two at 1.75 seconds.

The big questions now is if the type2-runtime gets compiled with a static glibc, will that also speed it up by 25%? It is very likely but not 100% certain. If so the 1.75 second delay will be 1.3 seconds.

[xplshn]

@Samueru-sama static linking is not the issue.
Dynamic linking calls the dynamic linker, inspects the symbol table, and finds the files which contain the symbols and opens them.

One of the biggest advantages of static linking is speed. GNU even needs to retain a cache of symbols and their files in order to make loading executables a tiny bit faster (yet not as fast as any statically linked executable).

An issue with linking Glibc is that it will call dlopen(), its just a matter of on which systems it will do so, since Glibc does not officially support static linking, and uses dlopen() an actual lot.

I think we should try to optimize the type2-runtime and uruntime, the type2 runtime currently does pretty wild stuff, and I find the code cumbersome, there are a lot of magic numbers, and a lot of uncommented sections of code accounting for edge cases.

About uruntime, its not immediately clear to me what optimizations could be done, but it is certain that relying on the compiler to make your code faster or the libc is not good practice, its better to improve the logic.

[brunvonlope]

250 milliseconds doesn't seem to worth the job 🤔. The 25% percentage creates the impression that the "bug" is bigger than it really is (at least for GUI appimages on which no one notices this)

[Samueru-sama]

Yeah the problem isn't static linking but static linking musl.

250 milliseconds doesn't seem to worth the job 🤔.

The thing is that in the uruntime the difference is from 2 seconds to 1.5 seconds, that half a second delay is very noticeable.

Right now the type2-runtime has a statically linked musl instead of static glibc, it is very likely that 25% improvement will also translate to the type2-runtime if it gets stattically linked to glibc or a different libc library.

it other words it would take 1.3 seconds instead of 1.75 seconds

[xplshn]

Yeah the problem isn't static linking but static linking musl.

250 milliseconds doesn't seem to worth the job 🤔.

The thing is that in the uruntime the difference is from 2 seconds to 1.5 seconds, that half a second delay is very noticeable.

Right now the type2-runtime has a statically linked musl instead of static glibc, it is very likely that 25% improvement will also translate to the type2-runtime if it gets stattically linked to glibc or a different libc library.

I would not use an unsupported feature of Glibc in prod

NOTE: The Libc comparison table offers info on this, and also, it is important to note that glibc has big chunks of code written in assembly, hacks to squeeze performance, glibc also internally calls dlopen(), meaning, that, even if a binary is compiled as a statically linked binary, it won't be 100% self-contained because an internal libc routine may call dlopen().

[Drsheppard01]

I think it's more important now to understand if there is a difference in performance depending on the choice of runtime environment for programmes like blender and obs

[Samueru-sama]

Alright any volunteers that want to compile the type2-runtime with different libc libraries to test? I actually have a Chimera container not sure how hard it could be lol