比较两个C ++迭代器的性能成本

Question

In general, what is the performance cost of an equality comparison between two STL container iterators? I'm only talking about defined operations; that is, comparing two iterators referring to the same object.

My specific use-case is that I have a std::map that could potentially have very large elements, lots of elements, or both. If an equality comparison between two iterators over such a map have hidden penalties that I'm not aware of, it could impact the performance of my code.

Answer 1

Generally, the performance of comparing two iterators depends on the implementation of the STL.

However, concerning the time complexity , the C++ standard imposes the restriction that comparison of input iterators (and thus forward iterators, bidirectional iterators and random access iterators) takes amortized constant time. Particularly, this means for an std::map<std::string, int> , that its iterators cannot be compared by comparing the keys for equality, because that would be linear with respect to the length of the key.

Answer 2

Most of STL containers operator==() is just raw pointer comparison. Which is meaningless unless it's for boundaries checking. More over, if you are comparing iterators from different containers - it's undefined behaviour.

If you override this operator or use external comparison function, perfomance depends on how large are object you are comparing.

Probably I got your question wrong, it's not 100% clear what do you mean by "iterator comparison" and what's your use case.

Answer 3

The draft Standard states that iterator operations are amortized constant time

24.2.1 In general [iterator.requirements.general]

8 All the categories of iterators require only those functions that are realizable for a given category in constant time (amortized). Therefore, requirement tables for the iterators do not have a complexity column.

If you look at the signatures of iterator operations, there are no parameters or return types that correspond to the underlying elements T themselves, only T* and T& are required. Even operator== does not have to directly compare two arbitrarily large elements T themselves.

However, this does not give a hard real-time upper-bound for iterator operations. In particular, iterators can do very costly bounds checking , but these Debug mode security guards can usually be left out in Release builds.