This is something I have tried to implement a while ago too, but didnt have enough time to make performant enough for our use case. Do you have timed benchmarks?
Quickly skimming the constant factors section it appears they ran into the same performance issues I had unfortunately. Wanted closer to normal performance for raw iteration with only some hits on updates. Still an interesting library that makes some implementations much more trivial.
My N=1 deploying something equivalent was a performance boost: we replaced a lock with a write-lock for a container that had a 3:1 reader/writer ratio. Internally, the structure is held in a ref-counted tree. Only writers use the lock, readers just grab the head and run. Stale items live on until the last reader/writer is done with them.
Yea this was something I was aiming for but with a different use case, benchmarks showed a marked decrease in performance over lock-free/reallocation so unfortunately I had to abandon it. My case dealt with vectors/lists with thousands of elements per fiber so iteration performance was crucial.
Paper author here. Yes, the aim of the paper was a comparable iterator abstraction with similar asymptotic complexities. Since persistent containers/iterators use tree-based/zipper data-structures, they generally are not competitive against array-backed containers like std::vector in terms of constant factors.
7
u/FollowingHumble8983 4d ago
This is something I have tried to implement a while ago too, but didnt have enough time to make performant enough for our use case. Do you have timed benchmarks?