This releases includes some pretty nice improvements to the usage of the crate.
If you want to know how the View types I talk about in the release post are built, take a look at my post from back when I contributed them:
This releases includes some pretty nice improvements to the usage of the crate.
If you want to know how the View types I talk about in the release post are built, take a look at my post from back when I contributed them:
The limitation of needing compile-time knowledge of the max size of the
Dequeis pretty rough though.In this case, it seems like a feature.
It does make me wonder why not use a bounded channel instead (assuming these tasks are shared between threads, maybe because it’s multi-consumer?) but a deque is more flexible if that flexibility is needed.
Personally, I can think of a use for this myself. I have a project where I’m queuing audio to play in the background, and using this kind of deque for the queue would work here as well (though I use a bounded channel currently).
There are also a lot of times when i’ve wanted a stack-only data structure to avoid allocations where these can theoretically come in.
Also worth noting is smallvec and compact_str crates. These are useful when you most of the time have small data that you want inline, but are OK with falling back to heap allocation for the occasional outlier.
I have used both inside structs to optimise cache usage. For these uses i tend to use rather short smallvec.
And smallvec in particular is also useful on the stack in a larger variant in hot functions where you might have a Vec that almost always is less than (say) 32 elements, but the program should gracefully handle the occasional long case. I found this offered a small speed up in some batch data processing code I wrote.