[TODO] feature: custom sampler for batch about fsrs-rs

[dae]

Could this perhaps be solved by just sorting the input Vec<FSRSItem> before feeding it to the batcher?

[L-M-Sherlock]

Could this perhaps be solved by just sorting the input Vec before feeding it to the batcher?

Partially, we can sort the Vec by length or other properties, and set shuffle=False for the batcher. But the batch size is still constant for all batch. It's not flexible.

[dae]

It looks like we can define our own BatchStrategy implementation if we need more control - I imagine we could input a Vec<Vec<FSRSItem>> and have our strategy just return one of the inner vecs each time. I wonder how much difference it would make in practice through? With items sorted by length, the necessary padding shouldn't be huge, and I (perhaps naively) imagine that the actual model fitting work would dwarf the time it takes to prepare the input tensors.

Edit: I wasn't considering the extra work that would need to be done at fitting time with the padded values. Maybe the impact would be larger than I expected.

[L-M-Sherlock]

Yeah, I haven't test the performance of burn in long sequence. But it's very slow for long sequence in tinygrad. It costs me 1 minutes for entire epoch. But 90% items with short sequences have been done in 20 seconds.

This feature is in low priority. We can implement #20 and #5 at first.

[dae]

On a moderately-sized dataset, the padding doesn't seem to make much of a difference - I see 11.75s vs 11.76s in the best of three runs.

diff --git a/src/convertor.rs b/src/convertor.rs
index 8b71ae6..099aff9 100644
--- a/src/convertor.rs
+++ b/src/convertor.rs
@@ -1,5 +1,6 @@
 use chrono::prelude::*;
 use chrono_tz::Tz;
+use itertools::Itertools;
 use rusqlite::{Connection, Result, Row};
 use std::collections::HashMap;
 
@@ -200,11 +201,13 @@ fn convert_to_fsrs_items(
 pub fn anki_to_fsrs() -> Vec<FSRSItem> {
     let revlogs = read_collection();
     let revlogs_per_card = group_by_cid(revlogs);
-    revlogs_per_card
+    let mut revlogs = revlogs_per_card
         .into_iter()
         .filter_map(|entries| convert_to_fsrs_items(entries, 4, Tz::Asia__Shanghai))
         .flatten()
-        .collect()
+        .collect_vec();
+    revlogs.sort_by_key(|r| r.reviews.len());
+    revlogs
 }
 
 #[cfg(test)]

[L-M-Sherlock]

On a moderately-sized dataset, the padding doesn't seem to make much of a difference - I see 11.75s vs 11.76s in the best of three runs.

I guess you forget to remove shuffle?

[L-M-Sherlock]

In my collection, the original convertor without shuffle costs 70.70s and the sorted convertor without shuffle costs 21.99s.

[L-M-Sherlock]

You can test this code: https://github.com/open-spaced-repetition/fsrs-optimizer-burn/tree/Feat/sort-FSRSItem-by-length

[dae]

You're right, I forgot about shuffling. That's a nice extra performance win!