Show all day calendar events reliably (despite memory limits)
Opened this issue · 1 comments
Background data is limited. Now it reliably loads just first 7 events from 8 events per calendar. The per calendar limit is tougher because the response json has lots of the data.
Either the background process or or background.exit method crashes when having less then then ~4800B of memory with ~760B data and ~420B auth-code.
Observed potential memory limits
-
8 full events per calendar / 8 with only dates: Out of Memory
-
14 total events with first 4 with full data: Watchdog Tripping
-
battery/memory consumption of additional WebRequest is yet to be found
Experiments:
-
9 events will be passed by clearing names/locations of events except for the first 4 events or with adding:
-
it should pass first events across he calendar, not first events just from the first calendars loaded
-
double events would be passed by parsing date strings (25B) to Time.Moment.value (4B)
- the parseISODate runs out of memory elsewhere, but converting just to Gregorian.Moment and solving a time-zone in bulk works.
-
14 events with 10 events per calendar would be passed parsing just time (5B) like 18:30 or 1830 if we load only events within 24h and resolve boundaries given by event start/end difference
-
14 events with 14 events per calendar would be passed if we request only start/end first and then summary/location only for first 4 events
-
over 14 would be passed by passing date as number instead of string, but crashes on Watchdog Tripping, so refactoring would be needed
-
Further savings?
-
WebRequests eats the memory and takes time. What if we load the calendar ids instead of indexes and save both requests and memory by loading directly the events data without the need to load the calendar id first?
-
refresh the idea with the paged calendars but making sure it does not run out of memory?
-
aren't nested cycles better from the memory perspective than the recursion?
-
read only start dates on the first request and then only load number of events that will stay within the limit
Ensure first events across calendars
- multidimensional array instead of calendar indexes would allow picking the first events across the calendar while more efficient insert-sort in LateApp as well
Beware the number of events passed can be decreased by the total memory available to the watch front-end
Any other ideas how to increase how many events are passed reliably and ensure those are the first events across the calendars, not just from the first ones.
7 events from 8 events from calendar is maximum to load now on Fenix6xPRO
watch has 29k memory, while background starts with 12k and sucessfully ends with having at least 4800
FR645m/FR245m/Vivoactive3m/Vivoactive4/4s have more free background memory
-
It doesn't apply to non-m versions or another non-music devices like Fenix6xPRO.
-
It loads up to 14 events, but then crashes on Watchdog Tripped Error instead
Link to subfeature: https://myneur.productboard.com/feature-board/planning/features/3338601