More performant implementations of standrard data structures


Today I saw a rust library called hurdles, which re implements std::sync::Barrier (exactly). Isn’t it better to merge this kind of perfomance improvements to the standard library instead of creating a 3rd party library. Am i thinking in a wrong way? I wanted to hear your thoughts on this kind of situations.


This seems to use the parking_lot crate and I think there is an RFC issue/PR discussion integrating/using this crate in std.

Oh, also:


Oh i see, but than that could be still put into std as an option. Still people can prefer hurdles’ implementation over std.


Generally this stuff is not “more performant”, it’s “has different tradeoffs”. That’s the case with parking_lot, at least. There’s no clear-cut reason to merge it.

Performance improvements to stdlib datastructures do get merged.

Folks often prefer to experiment outside of the stdlib before attempting to do that though. I don’t think that’s a problem.


Hey, author of hurdles here. So, hurdles doesn’t really use parking_lot. The only thing it uses from there is SpinWait which provides a more efficient way of spinning than a tight loop. I think hurdles::Barrier could theoretically be adopted into the standard library, as it provides basically the same properties, but there are two major hurdles (tihi) to overcome (see this GitHub issue):

  • hurdles::Barrier currently never parks the thread – it just spins instead (though it does call sched_yield). We could fall back to a Mutex + Condvar if we’ve spun for long enough, but that’s a non-trivial change.
  • hurdles::Barrier is Clone and takes an &mut self receiver since each barrier handle keeps mutable state. std::sync::Barrier instead expects to be wrapped in an Arc and called with &self, so the APIs aren’t directly compatible even though they are fairly similar.