Damn! I never knew thank you Ram Netwon A for sharing the video and Fred not only you showed the difference in runtime but you explained how you found it too thanks for sharing that I tried to look at contracts or spec or anything now I will try to do that more
So, if I understand it correctly, the graph on slide 51 would look different if k is very small compared to N. See also slide 45. We know both k and N when calling std::partial sort. Can't std::partial_sort be tuned to simply revert to (std::nth_element + std::sort) in cases where conditions aren't favorable, i.e. when k is a sizable fraction of N?
Damn! I never knew thank you Ram Netwon A for sharing the video and
Fred not only you showed the difference in runtime but you explained how you found it too thanks for sharing that I tried to look at contracts or spec or anything now I will try to do that more
So, if I understand it correctly, the graph on slide 51 would look different if k is very small compared to N. See also slide 45. We know both k and N when calling std::partial sort. Can't std::partial_sort be tuned to simply revert to (std::nth_element + std::sort) in cases where conditions aren't favorable, i.e. when k is a sizable fraction of N?
Interesting observation!
Interestingly, on slide 36 @ 9:55 VS2017 implementation has stable_sort() slightly faster than sort()!
It will be great to add timsort as std::adaptive_sort