Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding a persistent priority queue to the package? #190

Open
saolof opened this issue Jun 13, 2021 · 0 comments
Open

Adding a persistent priority queue to the package? #190

saolof opened this issue Jun 13, 2021 · 0 comments

Comments

@saolof
Copy link

saolof commented Jun 13, 2021

Hey, so first of all I wanted to say that I find this crate very useful. The main current omission is the lack of a persistent priority queue (ordered dicts and sets do not allow for multiple elements out of the box). Creating & microoptimizing one should be a fun problem; there is a fairly large design space of possible designs for an efficient priority queue (in fact, half of Okasaki's book on data structures literally seems to be about various heaps), so I felt that creating an issue here as a space to discuss various possible options including practical performance considerations,linking research papers & resources, and benchmarking of various options could be a good idea.

The first question would of course be which operations to prioritize. Since the mutable standard library bin-heap has abysmal merge-heap performance but fast everything-else and cannot persistently share data with earlier versions of itself, as a complementary design here it may be a good idea to pick one with fast O(log(n)) or O(1) merges and good performance as a persistent data structure.

With that said, since cache locality matters in the real world, a good starting point may be to consider a simple 32-ary heap with copy-on-write depending on node refcounts (so that inserts and pops would only need six heap accesses), and using it as a benchmark to compare any alternative implementation to.

( Edit: Incidentally, here's a nice paper by Larkin/Sen/Tarjan studying a range of mutable heaps, and finding that even in that domain it is not true that binary heaps are always king: https://arxiv.org/pdf/1403.0252.pdf )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant