You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
myneur
changed the title
Show all day calendar events reliably
Show all day calendar events reliably despite memory limits
Dec 15, 2019
myneur
changed the title
Show all day calendar events reliably despite memory limits
Show all day calendar events reliably (despite memory limits)
Dec 15, 2019
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)
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
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
The text was updated successfully, but these errors were encountered: