Improve performance of stats revlog entries with memory state #3866
Conversation
dae
left a comment
There was a problem hiding this comment.
Performance improvements are always appreciated! ❤️
| historical_retention: f32, | ||
| ignore_revlogs_before: TimestampMillis, | ||
| ) -> Result<Option<FsrsItemForMemoryState>> { | ||
| ) -> Result<(Option<FsrsItemForMemoryState>, Option<Vec<RevlogEntry>>)> { |
There was a problem hiding this comment.
This return value implies that one can be Some and one can be None, which is not the case. And FsrsItemForMemoryState is already a custom struct for holding the return value. Would it make sense to add a filtered_revlogs field to FsrsItemForMemoryState, and keep the return value here the same?
There was a problem hiding this comment.
This implementation requires the minimal modification of the current code.
There was a problem hiding this comment.
OK, I figured it out. Now the filtered_revlogs has been included in FsrsItemForMemoryState.
There was a problem hiding this comment.
Thanks, I think that's cleaner :-) If we find ourselves adding any further args to fsrs_item_for_memory_state() in the future, we'll probably want to do the same input struct treatment as you did over in the fsrs-rs crate.
This PR optimizes the memory state calculation in the FSRS scheduler by calculating all historical memory states at once instead of recalculating them incrementally for each review log entry.
Changes
fsrs_item_for_memory_state()to return both the item and filtered revlog entriesImplementation Details
The main change is in the
card_stats_with_memoryfunction, which now uses a more efficient approach:The
fsrs_item_for_memory_state()function was modified to return both the item and filtered revlog entries, which allows for proper mapping of memory states to review log entries.Benefits