Multiset vs. Priority Queue

5 years ago, # ^ |

← Rev. 2 →

-66

How is Priority_queue faster than a multiset?

Wont Deletion through an iterator take constant time in a multiset where as pop takes log(n) time in priority queue

→ Reply

5 years ago, # ^ |

+20

I don't know the implementations in C++ nor have I benchmarked the structures, but I would definitely expect priority queue to be faster, maybe even a lot faster. Why would you expect otherwise?

The functions of a priority queue are a subset of the functions of a multiset, if the latter is faster then the former is useless.

You can implement a priority queue through a heap structure, while for a multiset you need a balanced binary tree structure, which is significantly heavier.

→ Reply

5 years ago, # ^ |

-56

Agreed, but Wont Deletion through an iterator take constant time in a multiset where as pop takes log(n) time in priority queue

→ Reply

5 years ago, # ^ |

+16

It may be so, but that's not a great way to look at it. If you add $$$N$$$ elements and then remove them all, both priority queue and multiset will be $$$O(N log N)$$$ (and in fact no structure is faster than that, because you'd break the sorting complexity lower bound). Even if multiset is quicker in the deletion part, it likely pays a price for that during the addition part.

It may be interesting to properly compare them, but I'd be quite surprised if multiset turns out to be faster, as my experience has showed that set/map in C++ are incredibly heavy.

→ Reply

5 years ago, # ^ |

I get your point.

Thanks for helping me out!

→ Reply

gratus907

5 years ago, # ^ |

← Rev. 2 →

As far as I know, multiset is implemented as a balanced binary tree as Enchom mentioned. Since it should be 'balanced' after insertion and deletion, it has to do some 're-balancing' (algorithms can vary by implementation, but generally rotating trees). Unless it does that job, there might be some possbile occasions which a sequence of insertion and deletion makes multiset's internal implementation tree unbalanced and makes operation after that very slow (up to O(n))

To sum up, priority queue is a heap structure, which takes $$$O(\log n)$$$ time to delete top element. Multiset is a balanced binary search tree, which takes up to $$$O(\log n)$$$ time to delete anything and then assuring balance. Latter can be a lot slower (bigger constant factor).

Currently priority queue is somewhere 1.5x to 2x faster than multiset with compiler optimizations. (Depends on if you turned -O2 on, and bunch of other factors, including your compiler version and OS) There are some benchmarks in stackoverflow, which I haven't throughly read yet.

Edit : my friend pointed out that my numbers are wrong.

→ Reply

5 years ago, # ^ |

← Rev. 2 →

+24

According to this reference, he is actually right that deletion is amortized constant. I ran a few quick tests and indeed multiset deletion seems faster than priority queue deletion.

However, as I suspected and mentioned in my other comment, this is at the cost of a very slow addition in multiset compared to priority queue. Since you can't delete more elements than you add, I can't imagine a scenario where you'd prefer multiset only due to the faster deletion.

→ Reply

gratus907

5 years ago, # ^ |

Oh, I misread the question and considered erasing by value. I was talking about wrong thing then. Thanks for pointing it out.

→ Reply

5 years ago, # ^ |

+10

Right...

Maybe as gratus907 said, Addition in Multiset would probably be slower due to ReBalancing Algorithms (Rotating Tree).

Thanks once Again!

→ Reply

5 years ago, # ^ |

-29

Amortised isn't worst case, that's still $$$O(\log)$$$.

→ Reply

5 years ago, # ^ |

Worst case may be o(log) but the average time, ie the amortized time is constant.

Check out Enchom comment on this blog. He ran few tests, and found out that deletion in a multiset is faster than popping from a priority queue

→ Reply

5 years ago, # ^ |

-7

Yes, I read the comments before posting, unsurprisingly. It's just that when you don't mention that you're talking about amortised complexity, the assumption is that it's worst case.

There are implementation tricks for faster insert/delete operations for a lot of structures, for example deletion flags on nodes and lazy rebalancing. That's why I'm more interested in a test where insert/delete is mixed with searching, but that comparison is tough because heap doesn't have searching.

→ Reply

Kognition

4 years ago, # ^ |

-10

"It's just that when you don't mention that you're talking about amortised complexity, the assumption is that it's worst case."

This is a widely misunderstood point about amortization, but it is actually completely independent from the concept of "worst case" or "average case". Classical analysis only considers complexity on a per-operation basis, whereas amortized complexity is about analyzing on a per-algorithm basis. There is a nice rigorous definition regarding potential functions here that shows that if you sum up the amortized complexity over a sequence of operations, it will necessarily be an upper bound for the standard complexity summed over that sequence of operations (note that "worst case" is never referenced in this definition).

I also don't think it's necessarily correct that people default to not talking about amortized analysis. I actually can't think of a scenario where the amortized complexity is better than non-amortized complexity and we don't default to amortized (std::vector::push_back, for example). Curious to hear if you have contrary examples, though. It's quite late for me so my recall could be bad.

→ Reply

5 years ago, # ^ |

What's your point? Why would we care specifically about worst case complexity in this discussion? It is worst case $$$O(logN)$$$ to delete one element, but $$$O(1)$$$ amortized. This means if you were to delete all $$$N$$$ elements it'd be $$$O(N)$$$.

→ Reply

5 years ago, # ^ |

-35

Why would we care specifically about worst case complexity in this discussion?

Because that's normal?

→ Reply

5 years ago, # ^ |

Still don't get your point. Is your claim that when mixed with other operations, deletion will no longer be amortized $$$O(1)$$$? If that's true that's interesting, but I don't think it's easy to tell without knowing the specific implementation.

→ Reply

5 years ago, # ^ |

Not a claim, just one hypothesis. I'm wondering about the real implementation and what implementations there could be.

→ Reply

5 years ago, # ^ |

-22

NO. Deletion of anything in a balanced binary tree requires rebalancing, which is $$$O(\log)$$$. Whether it's through an iterator is irrelevant.

→ Reply

5 years ago, # ^ |

+15

check this out https://en.cppreference.com/w/cpp/container/multiset/erase

Deletion through an iterator takes amortized constant time in Multiset

→ Reply

5 years ago, # ^ |

-28

See my comment above.

→ Reply

Urbanowicz

5 years ago, # ^ |

Apparently, this is not true for red-black trees. Note that sorting lower bound doesn’t apply here as everything is already sorted and the node is already found.

→ Reply

Yuki726

5 years ago, # ^ |

I think pq is faster since it is cache friendly. pq's are internally stored in a contiguous memory(like vector), While multiset's are not.

→ Reply

5 years ago, # ^ |

← Rev. 2 →

UPD : Deleted

→ Reply

pritishn

5 years ago, # |

-53

The comments on this blog made me re-realize how much I still have to learn to become a Master. XD

→ Reply

nchn27

5 years ago, # ^ |

This blog post, unfortunately, did not make me a master :(

→ Reply

arthurconmy

5 years ago, # ^ |

I'm pretty sure there are many masters like me that don't know how multisets nor priority queues are implemented...

→ Reply

pritishn

5 years ago, # ^ |

-11

Just kidding bro, I was just amazed by how much detailed knowledge some people have regarding their languages. :D

→ Reply

Wild_Hamster

5 years ago, # ^ |

+11

grandmasters too

→ Reply

5 years ago, # |

-92

Multisets and priority ques are used only on Div1 E-F problems and top onsite competitions like ICPC WF, and are not needed to score well in CF rounds.

Personally I have never seen a reasonable problem that would require priority que during my CP career, and believe me, I consider myself experienced competitive programmer.

→ Reply

5 years ago, # ^ |

+23

Too young too simple...

→ Reply

5 years ago, # ^ |

20C - Dijkstra? is a classic problem that needs to be solved by Dijkstra algorithm with heap optimisation.

→ Reply

5 years ago, # ^ |

-45

Hmm, it is still alpha contest when CF was new and Mike just copied tasks. There is no such problem in recent CF rounds (about last 2 or 3 years).

→ Reply

5 years ago, # ^ |

What about 960B - Minimize the error? It's a Div. 1 + Div. 2 B with difficulty *1500.

→ Reply

5 years ago, # ^ |

-12

It can be solved in $$$O(n \cdot (k_1 + k_2))$$$. $$$k_1$$$ times choose $$$i$$$ such that $$$a_i - b_i$$$ is largest and decrease $$$a_i$$$, then do the same for array $$$B$$$. I don't see how priority que or multiset can be utilized here.

→ Reply

5 years ago, # ^ |

See the tutorial please.

"This can be implemented using a priority queue or by sorting the array C and iterating over it."

Although this problem has a solution which doesn't need priority queue, it seems that priority queue is well known by most competitive programmer according to the sentence.

→ Reply

5 years ago, # ^ |

-16

Well, according to my comment above it's not well known. Or do you believe thousands of grey coders actually know multiset and priority_queue?

→ Reply