Is your feature request related to a problem? Please describe.
I'm always frustrated when:
The Calendar granularity is limited by memory and lookup efficiency. It takes a few seconds on a relatively performant mobile phone to recalculate my Calendar currently, for only two weeks - and using 1h granularity. The reason is that representing each smallest time slot of a Calendar as a separate entry in a Vec is not space or lookup efficient.
Resolving this issue would also allow for #394 while maintaining/improving performance.
Describe the solution you'd like
Make Calendar data storage and finding/counting of Slots more efficient by using ranges.
There have been thoughts about this (using ranges in a B-Tree or adapting interval tree) - but so far I've never encountered an example of an implementation specifically designed for storing non-overlapping ranges and the gaps in between. Maple Tree seems to fit. Linking to that via FFI or more likely rewriting it in Rust (as a separate Rust crate so others can use it too) could be a solution. The ZinZen use case, unlike Linux, is single-user - and can be optimized differently. Also, it needs to store information on the number of claims per null range - and which activity claimed wich range.
Describe alternatives you've considered
Not increasing granularity. Not an option.
Optimizing current brute-force 'walking' the Calendar with caches / smart logic like suggested in #394
Is your feature request related to a problem? Please describe. I'm always frustrated when:
Resolving this issue would also allow for #394 while maintaining/improving performance.
Describe the solution you'd like Make Calendar data storage and finding/counting of Slots more efficient by using ranges.
There have been thoughts about this (using ranges in a B-Tree or adapting interval tree) - but so far I've never encountered an example of an implementation specifically designed for storing non-overlapping ranges and the gaps in between. Maple Tree seems to fit. Linking to that via FFI or more likely rewriting it in Rust (as a separate Rust crate so others can use it too) could be a solution. The ZinZen use case, unlike Linux, is single-user - and can be optimized differently. Also, it needs to store information on the number of claims per null range - and which activity claimed wich range.
Describe alternatives you've considered
Additional context lib/maple_tree.c
lib/test_maple_tree.c