I have a single line of code, that consumes 25% - 30% of the runtime of my application. It is a less-than comparator for an std::set (the set is implemented with a Red-Black-Tre
I have many insertions for each extraction of the minimum. I thought about using Fibonacci-Heaps, but I have been told that they are theoretically nice, but suffer from high constants and are pretty complicated to implement. And since insert is in O(log(n)) the runtime increase is nearly constant with large n. So I think its okay to stick to the set.
This sounds to me like a typical priority-queue application. You say you just considered using a Fibonacci heap, so I guess such a priority-queue implementation would be sufficient for your needs (pushing elements, and extracting the min element one at a time). Before you go out of your way and obsess on optimizing one or two clock cycles out of that comparison function, I would suggest that you try a few off-the-shelf priority-queue implementations. Like std::priority_queue
, boost::d_ary_heap
(or boost::d_ary_heap_indirect for a mutable priority-queue), or any other boost heap structure.
I encountered a similar situation before, I was using a std::set
in place of a priority-queue in a A*-like algorithm (and also tried a sorted std::vector
with std::inplace_merge
for insertions), and switching to std::priority_queue
was a huge boost in performance, and then later switching to boost::d_ary_heap_indirect
went the extra mile. I recommend that you at least give that a try if you haven't already.