Profiling turned up _Iterator_base12::_Orphan_me. What is it?
I just finished profiling a block of code which took up too much time. The code in question creates a large boost::graph from some std::vectors and a std::set, which are sorted and inserted into very many times. However, I was surprised to see that the majority of the time was not spent in sorting or inserting, but in std::_Iterator_base12::_Orphan_me
- 97.27% reported by AMD CodeAnalys开发者_C百科t. What is this function? It seems to be called ~2200 times, the total runtime is ~30 seconds.
CodeAnalyst doesn't give me a very good call stack, and seems to cut names after 120 or so characters, which is no match for a boost template type. If there is a way to improve this (I'm quite new to CodeAnalyst), please say so and I might be able to give better information.
The answer is to run the profiler in the Release mode, see performance killer -Debug Iterator Support in Visual studio.
Iterator checking, enabled by
_SECURE_SCL
, performs minimal checks that serve as a last line of security defense... Because it is enabled by default in release mode, strives to impose minimal performance penalties. Therefore, when it is enabled, although iterators have pointers back to their containers, containers don’t have pointers to their iterators...The Swap Fix in Orcas makes every Standard container own an additional dynamically allocated object, imaginatively called "the
aux
object". Each container holds a pointer to itsaux
object, which holds a pointer back to the container. Each iterator, instead of holding a pointer directly to its parent container, now holds a pointer to its parent container’saux
object...The performance issue is that the
aux
object, while unavoidable... is not free. Each Standard container is now larger because it has to hold a pointer to itsaux
object. Theaux
object has to be dynamically allocated, occupying more space and taking more time. And_SECURE_SCL
has perform a double indirection when going from an iterator to its parent container.
精彩评论