Skip to content

Tune BinaryHeap / sift down #29969

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

Closed
bluss opened this issue Nov 21, 2015 · 2 comments
Closed

Tune BinaryHeap / sift down #29969

bluss opened this issue Nov 21, 2015 · 2 comments
Labels
A-collections Area: `std::collections`

Comments

@bluss
Copy link
Member

bluss commented Nov 21, 2015

See PR #29811

Find out in which cases the eager placing sift down (current / new version) is better than the sift down fully, sift up again algorithm.

Look at both From and pop() etc.

I intend to work on this, just write something to give datasets of various patterns and evaluate, but let's track it so that it doesn't get lost. Also, if I'm slow, anyone is super welcome to pick it up.

@bluss bluss added the A-collections Area: `std::collections` label Nov 21, 2015
@bluss
Copy link
Member Author

bluss commented Dec 12, 2015

My results are in, see gist

  • New (current) code is a win for small element counts regardless, and many cases in general
  • Only a slower pop for the many elements, slow compare (string) case is concerning

Plan to remedy:

  • Restore old sift_down behavior specifically for pop and replace; other methods continue using “eager” sift down

@bluss
Copy link
Member Author

bluss commented Dec 12, 2015

cc @dgrunwald

bors added a commit that referenced this issue Jan 11, 2016
BinaryHeap: Use full sift down in .pop()

.sift_down can either choose to compare the element on the way down (and
place it during descent), or to sift down an element fully, then sift
back up to place it.

A previous PR changed .sift_down() to the former behavior, which is much
faster for relatively small heaps and for elements that are cheap to
compare.

A benchmarking run suggested that BinaryHeap::pop() suffers
improportionally from this, and that it should use the second strategy
instead. It's logical since .pop() brings last element from the
heapified vector into index 0, it's very likely that this element will
end up at the bottom again.

Closes #29969
Previous PR #29811
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-collections Area: `std::collections`
Projects
None yet
Development

No branches or pull requests

1 participant