What causes the long delays which switching or starting apps?

[motox6]

I was watching top via an SSH session.

When I select a new app there is a long delay before the new app shows up on the screen.

I had expected to see something like high CPU usage, or perhaps high io wait while the app is loading.

But I see neither.

What is going on during the long app startup times?

Do other people experience this behavior?

[TRS-80]

Assuming you are on Mobian (I am). I see the same behaviour.

My assumptions would have been same, so that's interesting what you observed via top.

On Android for instance, lots of stuff is actually kept in memory for fast switching / better user experience.

[Zebulon Walton]

I've noticed this as well. (It's hard not to!) My assumption has been that it's due to the low speed of eMMC and SD cards causing long load times.

[TRS-80]

Indeed, I am running Mobian off of SD card.  Probably good to get used to that, then when I switch to eMMC later it should be noticeable improvement. 

[Zebulon Walton]

Indeed, I am running Mobian off of SD card.  Probably good to get used to that, then when I switch to eMMC later it should be noticeable improvement. 

It does run a bit faster off of the eMMC but programs still take their time loading.

[motox6]

Very interesting that the I/O wait time is not reflected in iowait in the CPU stats.
One would think the CPU would be busy somewhere.

root@mobian:~# dd if=/dev/mmcblk2 of=/dev/null bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 16.0952 s, 52.1 MB/s

52 MB/s seems pretty fast. (though it is sequential and not random)

[LibrePhoneUser]

My understanding is that a lot of the delay is due to the GTK+ interface of Mobian apps not being accelerated on the PinePhone's graphics hardware.

[swiley]

Some Xorg WMs are just slow. I've noticed fluxbox can take it's time opening new windows while FVWM does not. There's probably something similar going on with Phosh. Then there's loading all the SOs and whatnot that might not be cached.
I highly doubt GPU acceleration has much to do with it. It might even make things worse by taking memory that could be used for disk cache and using it for compositing instead, but I don't know enough about the pinephone hardware to really know for sure.

[lacriz]

I've noticed this as well. (It's hard not to!) My assumption has been that it's due to the low speed of eMMC and SD cards causing long load times.

I second your assumption. As mentioned in this forum, the eMMC has about 65 MB/s read speed.
For comparison, the built-in SSD memory of the iPhone SE 2nd gen has  - wait for it  -  439 MB/s read speed (german site )

I ran:

Code:

perf top

while starting up the gnome Maps app and by far the most frequent sys call (about 16% of all calls during startup - not accounting for how long each call takes [!] ) is:

Code:

do_lookup_x

which is the syscall used to load e.g. .so files etc. during startup.


To me this means the only chance to have faster-starting apps is to have apps which actually start faster (d'oh). Meaning it is not up to the distro or upstream, but it is up to the app devs to speed their apps up. A way to do that without having to change any code is to link the whole application statically. This results in a (way) larger application executable but gets rid of additional file i/o during app start.

For end users the only way to go for now seems to look for apps with smaller footprint and try them out.
I would love it if linmob or the mobian wiki would list the startup time, just roughly in seconds would be great!

[lacriz]

A possibility is to install the preload daemon. Mixed results so far: https://forum.pine64.org/showthread.php?...#pid101574