Switching from clock to launcher currently needs 3.83 seconds for me, which feels like a LOT.
Ouch - yes! I'd be really interested if you could figure out what's taking the time there.
But yes, I think the clock -> launcher transition is one where it does make sense to try and avoid the load(). Even if there are leaks at least it only happens once at the moment so won't cause a huge build-up.
With widgets: loading these can take a decent amount of time, and personally I think trying to handle loading/unloading them automatically when switching apps is just a step too far. If you're not careful you end up doing so much extra work that even after all this, load times will not be significantly better than if you just did load()
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Ouch - yes! I'd be really interested if you could figure out what's taking the time there.
But yes, I think the clock -> launcher transition is one where it does make sense to try and avoid the
load()
. Even if there are leaks at least it only happens once at the moment so won't cause a huge build-up.With widgets: loading these can take a decent amount of time, and personally I think trying to handle loading/unloading them automatically when switching apps is just a step too far. If you're not careful you end up doing so much extra work that even after all this, load times will not be significantly better than if you just did
load()