Performance Considerations for various containers (vector,deque,map,set,unordered_map,unordered_set,list) of the C + + standard library

Transferred from: http://blog.csdn.net/truexf/article/details/17303263

First, Vector

Vector uses a contiguous memory to store its elements, adding elements to the vector, if the capacity is insufficient, the vector will re-malloc a larger chunk of memory, then memcpy the original memory data into the new memory, free the original memory block, and then add the new element. The element insertion performance of vectors is significant in relation to the following elements:

1. Where to insert

Head insert: Move all elements back and insert the new element

Middle Insert: Moves the element behind the insertion point back and then inserts a new element

Trailing insert: Inserts a new element directly into the trailer

The trailing insert is undoubtedly the fastest, the head insertion is slowest, the middle insertion is second, and the slow point is the memory to be moved before inserting.

Deleting elements is the same thing.

2. Reserved space size

If the element is inserted, insufficient space will result in a re-malloc and a series of memory copies. If the user can expect the capacity, then using reserve () to pre-allocate memory, will greatly improve performance.

3. Library implementation related to memory expansion algorithms

When the lack of space leads to the need to re-malloc, different library implementations are very different, often the implementation of specific platforms will combine the platform features of the operating system and the malloc algorithm to provide a very good memory expansion algorithm, in the million vector<int> insert operation, Without reserve (), performance is excellent. Close to the use of the reserve ().

Because vectors use contiguous memory to store their elements, the subscript method of supporting elements is randomly accessed, and the time complexity is constant 0;

If you are looking for an element, the find () member function of the vector finds the element by scanning from start to finish, his time complexity is O (n), and if the vector is to cope with the performance requirements of the lookup, then the vector of sorts should be taken, The Getlowerbound () of the algorithm library is used to make an orderly insertion of elements, and the Binary_search () is used to find the elements in two points. In this case, the lookup performance is not lost in the red and black tree based set and map, but also to the list.

In summary, vectors are suitable for trailing inserts, but it is not possible to take into account the performance of lookups, as the vectors of the binary lookup require reordering, or the vector is ordered to remain in order at insertion, so that the trailing insertion is not possible.

But Vector is good enough as an alternative to dynamic arrays.

Second, deque

Deque uses multiple blocks of memory to provide the element's error, each memory block stores multiple elements, and each chunk of memory stores the same number of elements, which is different from the way vectors use a piece of memory to store all the wrong elements. The benefits of this are:

First, the cost of inserting/deleting elements at the head and end inserts is the same, which makes up the problem of the poor performance of the vector and the head insertion element.

Second, for a vector of a block of memory pattern, when there are a large number of elements, the operating system of large memory allocation and assignment is very slow, and the deque way does not bring this problem.

The disadvantages are:

First, the element's access needs to go through two levels, the first time the element is located in the memory block, the second time to find the elements in the block. But this time is almost negligible, unless the performance requirements are extremely stringent.

Second, sorting them, and sorting after the search will be slow, imagine the well-known sorting algorithm for a continuous memory for subscript access, and deque is a discontinuous memory block composition. Similarly sorted binary lookups cannot be compromised by direct access to natural performance by subscript.

Third, List

The list is simple, he is a doubly linked list. The memory of each node is independent. Theoretically, the advantage is that any insertion of a delete element in any position is a very block operation. The disadvantage is that it is not suitable for element lookups, as he can only be scanned in a way. According to the actual test situation, I think the list is not worth a use, because the frequent addition and deletion of nodes will result in a lot of repeated memory allocation and release operations. In fact, the operating system and the runtime memory allocation and release frequency and policy is the most important to affect the performance of the STL container is the most critical point.

Iv. Map/multi_map/set/multi_set

These four data structures are stored in memory using a balanced tree (red-black tree) to implement its elements. Theoretically (as is the case with list) their performance is very high, and in the insertion/deletion and element lookup on the balance point is quite good, the specific algorithm complexity can refer to the red and black tree algorithm literature, but also based on the " The principle that the operating system and the memory allocation and release frequency and policy of the runtime are the most critical points in the performance of the STL's large containers.

Five, the hash container unordered_map/unordered_set/unordered_multi_map/unordered_multi_set

C++11 introduced in the hash container, the hash container has instability: he relies on the actual hashing algorithm used. Different hashing algorithms have significant performance differences for different element numbers.

So, theoretically (and theoretically) their algorithmic time complexity is almost "constant" (not if the conflict is to be handled). However, the use of time for the average user may pose a risk. Unless you have a good estimate of the hashing algorithm and the number of elements you are using. In my simple test (using the int element type, the default hash function of STD), the performance of the hash container is ranked at the bottom.

Vi. "Memory allocation and release frequency and strategy are the most critical points that affect the performance of STL's large containers"

This is very important. Different operating systems, different runtimes, his virtual memory management algorithms, and the runtime's internal implementations of malloc and free are all different. How to find the most efficient way to use standard storage, it is necessary to combine this to a large number of tests can be obtained.

One thing to be sure is that the implementation of each standard library is already based on the C + + standard and can be said to be the ultimate in performance and applicability. So a lot of people always want to make a repeat of the wheel is big can not. Understanding the principle of various containers, combined with the actual application of the needs, the choice of suitable containers, and the use of containers, is the best strategy.

Performance Considerations for various containers (vector,deque,map,set,unordered_map,unordered_set,list) of the C + + standard library