The story around this project is a bit of a weird tangent. I'm working on another project (not ready to share) that uses tokio and needs to delete a bunch of files. I was surprised to discover that tokio's remove_dir_all implementation forwards to the stdlib, meaning it is completely sequential. To squeeze out every ounce of performance, I decided to write a crate that deletes files in parallel as fast as possible (still WIP), but to do so, it turns out I need a way to reliably and deterministically generate a bunch of files to delete so I can benchmark deletion performance properly. So here I am, finally popping that third plate off the stack. :)
FTZZ is designed (and optimized) primarily for Linux, but also works on macOS and Windows.
FTZZ is insanely fast and will saturate your machine when creating empty files — I can reach 800K files/s on my laptop. I'm considering the project complete, but it still has a few flaws:
- Memory usage is not fully bounded, meaning you could theoretically run out if you try to generate a tree billions of directories wide.
- The error between the target number of files and the actual number of generated files grows with the maximum depth of the tree. I'm using a LogNormal distribution, but probably incorrectly.
- When generating an exact number of files or bytes, their distribution can get messed up because I haven't looked into how to properly distribute the remaining files/bytes.
1 comment
[ 3.1 ms ] story [ 10.2 ms ] threadFTZZ is designed (and optimized) primarily for Linux, but also works on macOS and Windows.
FTZZ is insanely fast and will saturate your machine when creating empty files — I can reach 800K files/s on my laptop. I'm considering the project complete, but it still has a few flaws: - Memory usage is not fully bounded, meaning you could theoretically run out if you try to generate a tree billions of directories wide. - The error between the target number of files and the actual number of generated files grows with the maximum depth of the tree. I'm using a LogNormal distribution, but probably incorrectly. - When generating an exact number of files or bytes, their distribution can get messed up because I haven't looked into how to properly distribute the remaining files/bytes.
If you want a more in-depth dive into the technical and performance details, I wrote up a blog post about them: https://alexsaveau.dev/blog/projects/performance/files/ftzz/.... If you think this project is cool, please consider upvoting my Stack Overflow answer: https://stackoverflow.com/a/69714764/4548500.