Others
Currently we use two vectors in collection (which is better than the many vectors we used before). One is used for root-tracking/DFS (depth first search) and the other stores the...
We can probably allocate less in this method, and `rayon` could be used to speed up the scanning process.
We will always depend on `alloc`, but it'd be nice to have a feature flag for switching to a `no-std` mode. Implementation notes: - this would involve factoring out the...
The Lockout mechanism is basically a shitty read/write lock. We could replace it with a single monitor/condition variable around collection. I don't know if that would help or hurt performance....
We provide `trace!` logs for collection introspection, but we should probably log in more places than that. (For example, when a drop fails?)
Probably will take the form of a blog post from me
This is a bit of a speed-bump for ergonomics. Could we use something like [fragile](https://github.com/mitsuhiko/rust-fragile) to ease this burden on users?
The current system is very under-optimized--although probably fine for basic use. This probably requires some good benchmarks so we can test some different setups. We also should probably respond to...
Without good benchmarks of `shredder` in use, it's difficult to optimize the implementation
We probably don't need complete coverage for our `Scan` impls, but I think we need a bit more coverage than what we have.