Async/Multithreading

[Shadow53]

SInce multiple hoards can be processed at once and each one may have multiple files, it may make sense to have multiple operations perform at once.

Not sure if this is best done with an async runtime like Tokio or making some background worker threads myself. A worker queue of some sort makes sense. I'll have to look into what is simplest to implement.

[mmstick]

You could look into smol. But know that File I/O is blocking anyway, so introducing async thread pools is not going to make File I/O any faster. You may be better off just having a background thread for sending all I/O tasks to. Doesn't necessarily have to be async, but you could leverage smol's primitives (such as async-io) if you want to ensure files in the background thread are successfully writing before proceeding to the next CPU task.

[Shadow53]

After thinking on this further, I agree that multiple threads for just file I/O doesn't really make sense. What may make sense -- and I will benchmark it when the time comes -- is using multiple threads to work with encrypted files, e.g. threads each for reading, en/decrypting, and writing. Again, I'll need to benchmark that to see if it is even worth the extra complexity.

[Shadow53]

Update on this: I created the fs-optimization branch to explore this.

• Processing time drops from 10 minutes to ~1 when using multi-threaded tokio over single-threaded std
• Some existing code needs to be refactored to avoid async recursions, as it seems to be causing stack overflows on Windows.
• The (admittedly fragile) tests for hoard edit stall on Linux, but seem to be fine on Windows. Behavior is manually tested to work correctly on Linux, so it's a problem with the test itself.
  • The test is the most complex of all of them, and I'm not sure the complexity and fragility is worth the slight increase in test coverage numbers. Probably better to just make sure things work manually and let that be good enough -- the logic shouldn't change much anyways.