POC - Combining BW Clock and Desktop Launcher to spend less time "Loading..."

You are reading a single comment by @halemmerich and its replies. Click here to read the full conversation.

•

Gordon
Maybe an alternative to this would be keeping the widgets loaded, but hiding them in apps not loading widgets?

Yes, I think that would be best - if it were implemented in a library it should be pretty easy to include.

Wrt timings:
- As far as I can see quicklaunch really has no need to load the whole apps list at boot. It might as well just check that appname.info exists when it's time to load the app.
- BTHRM is huge and I imagine just parsing that takes a while - there was some talk of trying to strip down what goes into the boot code (or maybe resurrecting the old one as a lite version? the original has 70 lines of boot code, not 630).
- I just looked, and again sensortools is another 350 lines of boot code so that won't be quick either.
- You say you're timing to iconlaunch displaying? If quicklaunch is that slow then I guess iconlaunch loading every app's icon file before it displays everything (launcher does this too though) could really slow it down. How many apps do you have?
I suppose it could be an option to extend the bootloader code such that there was an option to show the load times of each section?

I think my concern is your watch is slow because there's a huge amount of extra stuff that's been added to it. Personally, I feel like rather than adding more code to try and work around that, it'd be best to work on finding out what's slow and then optimising those bits, because I think there's some really low hanging fruit there.

For instance if the launcher is slow, potentially there might be a way of pre-parsing all the apps into a single JSON file (much like the bootloader adds everything to one file and uses .hash to check for changes). Icons could also be loaded as-needed since you only need to load the first 9 before you display the first page of the icon launcher?

I'd have thought that with a bit of work between the various apps/widgets/boot code you could maybe even double boot speed, and that would then apply to everything

•

halemmerich in reply to @Gordon
Loading the widgets and manipulating the loadWidgets/drawWidgets/draw-methods to just do nothing in case an app has not loaded widgets seems to work a treat. I believe the only way for widgets to disturb graphics is now drawing outside of the draw method. This could be handled by giving the widgets a dedicated buffer like widhide does.

I have implemented some changes for logging boot times:
```
Boot times:
  sensortools.0.boot.js: 302ms
  bthrm.0.boot.js: 151ms
  agpsdata.boot.js: 14ms
  android.boot.js: 61ms
  calibration.boot.js: 17ms
  fastload.boot.js: 17ms
  health.boot.js: 44ms
  owmweather.boot.js: 68ms
  qmsched.boot.js: 24ms
  quicklaunch.boot.js: 622ms
  sched.boot.js: 49ms
  swscroll.boot.js: 11ms
Boot took 1592ms
```
So actually BTHRM is not even that bad ;)
Sensortools is easy to fix, just moving everything into a lib and requiring only if enabled should help. BTHRM not that easy, tried 2 times now and did not manage meaningful size reduction without losing features I want. Quicklaunch is probably easy to fix as @rigrig said.
Iconlauncher takes about a second to load on my 40 app bangle, probably relatively easy to alleviate that by loading apps/icons as needed instead of all at once as you suggested.

But, currently I can with very little effort remove these 1.6 seconds altogether by just not needing to execute the boot files between app changes (or at least from launcher to app). Besides that I think optimizing single apps is currently more important than fastloading, even if I personally like the efficiency of not tearing down the environment for every app change. That will probably bring down the time to around half a second on a big install like mine. Probably good enough for most usecases.

Comparison between nearly empty bangle on 2v15 without fastloading and 2v15.40 with fastloading shows a nearly halved time from clock to launcher and about 10% faster the other way round (Anton and Launch). Although in this setting both seem to be very similar to the naked eye.
Espruino itself seems to take roundabout 80ms between load() and the first line of .boot0

There remains one point where fastloading has a real benefit:
Not losing state in BT and sensor stuff. Reconnecting in BTHRM takes some time and I think keeping a gps fix alive is also beneficial in comparison to aquiring it new on every app change. If I use GPS I currently think twice about changing the app as not to loose a fix which I then sometimes can not get back.

I will keep playing around with the fastboot idea in my apploader and try to get some PR in for low hanging fruit :)

About

Avatar for halemmerich @halemmerich started