Quote:
std::_List_iterator<dust, dust&, dust*>::operator*() const
std::_List_iterator<dust, dust&, dust*>::operator->() const
These are the functions that actually access the data so it's not surprising they come at the top. All this says is that you are doing a lot of data accesses.
Here are the definitions for those two functions:
reference operator*() const{ return static_cast<_Node*>(_M_node)->_M_data; }pointer operator->() const { return &(operator*()); }
Considering that they are actually inlined, there's not much (i.e. nothing) you can shave off.
I would suspect that the profiler caused them not to be inlined, possibly artificially inflating their "cost" (i.e. viewing as a function call something that would just be done as a couple of pointer indirections).
Quote:So with this in mind, is there any way to optimize how I use the STL library in those code snippets?
You could do fewer data accesses.
You could grab a reference to the element the iterator points to and use that instead of dereferencing the iterator multiple times. That should placate your profiler (fewer function calls, regardless of inlining), and possibly actually improve performance.
dust& ref = *it;glVertex2f(TransulatePoint(ref.x+(dustWidth/2),true), TransulatePoint(ref.y,false));
Grabbing a reference to an object whose location is determined by a potentially expensive function is a common trick.
Another option, for those cases where you do not need to refer to the original variable anymore, would be to make local copies of whatever data you need (here, it->x and ref.y) and be done with it. It may improve cache performance.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan