Say player clicks on object and camera is at an angle where their could be 10 objects in a line one behind each other when doing the ray test, this shouldn't happen very often but seeing what I see so far, I am switching to the multimap version.

You mean something like:

bool compare(const std::pair<double, Obj*>& left, const std::pair<double, Obj*>& right)
{
return left.first < right.first;
}

// Assuming you have an unsorted container of std::pair<double, Obj*> objects (like a std::vector)
std::vector<std::pair<double, Obj*> >::iterator min = std::min_element(myList.begin(), myList.end(), compare);


This code is O(n), even if you completely clear your vector every update. Using multimap or priority_queue is O(nlogn), assuming you clear them every update. However, taking SHilbert's advice into account, you can do the min tracking yourself (which is still O(n), but should require one or two less iterations over the container and book keeping required by the container, and thus potentially slightly more efficient than the above code).

*snip*

Yes, there are major differences between multimap and priority_queue in addition to the key/value thing. However, in that post I wasn't pointing out how different they are to implement, I was pointing out how different they are to use. Idiomatic uses of key/value maps or just value containers are quite different. And yes, you could abuse your toolbox and use them in a fairly similar manner (though not totally the same) with a couple unwieldy tricks, but I specifically advised against that. Proper use of these containers is quite different, because you use them in quite different situations.


struct GreaterSecond : std::binary_function<T, T, bool>
{
inline bool operator()(const T& lhs, const T& rhs)
{
return lhs.second > rhs.second;
}
};

typedef std::pair<NX::Object*, double> data_t;
typedef std::priority_queue<data_t, std::deque<data_t>, NX::Utility::GreaterSecond<data_t>> queue_t;
queue_t q(pickObjects.begin(), pickObjects.end());



Is what I was using when I did the priority_queue....

Which isn't just a simple insert... (because it's not an insert at all)

Really though, it would be very helpful if you were very clear on exactly what it is you're trying to do, and how you've tried to do it so far. You can't expect anyone to give you any meaningful help if you ask a question without much detail, then say it's X (just a simple insert), and then show us you've been doing Y (that's not an insert).

Optimizations aren't general. They're specific.* The fact that you're using the constructor to insert a range of things and not inserting them one by one makes a huge difference (by the way, the code you posted is O(n), with at most 3n comparisons being done, which isn't too bad). It shows that you a) already have the objects in an accessible, iteratable (is that a word?) data structure, b) either you only care about the top element, c) or maybe you just care about iterating through them in specific order. Your optimal solution depends on how many objects you're picking, how many objects you're picking from, what data structure these objects are stored in, how their distance is calculated, whether or not results can be reused, and even more details. None of which you've answered. Details are vital here, and so far all of your posts have been <= 3 sentences long.

If you're only picking one object, [font=courier new,courier,monospace]std::min_element[/font] will be up to ~3 times faster than your priority queue. If you're only picking from a few objects, you're probably optimizing the wrong thing.

[size=1]*generally speaking

[edit]

Glad to hear it worked well for you