Why does the Clock app take >5s to load?

Applications
1

I love Linux for it’s efficiency, principles and design.

But the Jolla clock app takes >5s to load on my Xperia 10II.

It may seem like nitpicking but this is an app I use everyday and I can’t understand why such a simple, core app could be so slow?

Any hints, suggestions or workarounds gratefully received.

2

On my side it needs 3 seconds to start. Xperia 10.

1 Like
3

Spot-on. X10II 3s here, still long indeed but as long as Media Player. There are many apps loaded in less then 1s/

4

So what is going on with the clock app?

5

My Xperia 10II takes approx 3 secs to open the clock app.

You could try “refreshing” the clock app, it may help, it may not;

devel-su pkcon install jolla-clock --allow-reinstall

I note that any saved alarms/timers are kept when reinstalling jolla-clock.

6

it’s not just the app, these days it involves at least sadboxing (in addition to all other inefficiencies along the way). it could also be that you’re running out of physical memory (especially if android runtime is running)

3 Likes
7

EDIT: the below is wrong, sailjail does not delay app startup, at least not by the huge factor i found. it delays on exiting with sigterm, which is slightly annoying.

to add to what slava is saying, sailjail is the complete, correct answer to your question.
i ran the following commands, watching the phone and hitting ctrl+c as soon as my alarm loads (i have just one alarm). i took the averages of 10 tries each. it’s fully twice as slow with sailjail to load

time jolla-clock = 1.51s (median 1.56s, min 1.48s, max 1.72s)

time /usr/bin/sailjail -p jolla-clock.desktop /usr/bin/jolla-clock = 3.06s (median 3.21s, min 3.02s, max 3.89s)

5 Likes
8

2 Seconds on Jolla C2.

1 Like
9

I would love to see startup flamegraph of various SFOS apps. But my Xperia 10.II have no linux-utils available :frowning: Does C2 have it? Anyone who is able to run “perf record” and generate flamegraph from it?

3 Likes
10

sorry folks, my test was flawed. i did not notice until repeating the test with other apps, but the huge sailjail overhead is on app exit.

i re-did the test with this setup:
pkill -f -9 /usr/bin/jolla-clock ; time sh -c 'sh -c "/usr/bin/jolla-clock &"; read'

pkill -f -9 /usr/bin/jolla-clock ; time sh -c 'sh -c "/usr/bin/sailjail -p jolla-clock.desktop /usr/bin/jolla-clock &"; read'

and i got 1.40s for no sailjail and 1.56s for sailjail. sailjail must be doing some cleanup on exit, at least on sigterm. there is some overhead for startup, but it seems to be constant and small.

1 Like
11

No worries, thank you for looking into this.

So we’re back to the app; anyone from Jolla?

12

They are on vacation. I’m sure they’ll answer when they see this (max couple of weeks).

1 Like
13

During my previous experiments with OSMScout startup delay I found that QML scene compilation takes pretty long, when you have non-trivial UI. It may be solved by distribution of pre-compiled QML files. But it is available from Qt 5.10 if I remember correctly and we are stuck on 5.6.

BUT clock UI is pretty simple (didnt ispect the sources), I would not expect that it is the bottleneck here.

I remember that app start was pretty instant on Jolla One because of launcher pre-loading. But it was abandoned because of Sailjail.

1 Like
14

I think another thing that eats time is DBus.

If the app needs to register names, services it can take a bit. Even more so if whatever causes starting things that provide DBus services.

For example, if there is a daemon providing org.foo.Service but it is not running and Sailjail/Firejail for app bar includes something like dbus-user.talk org.foo.Service, this will cause the daemon to be launched before app bar is displayed.

1 Like