Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

std::unordered_map very high memory usage

Yesterday i tried to use std::unordered_map and this code confused me how much memory it used.

typedef list<string> entityId_list;
struct tile_content {
   char cost;
   entityId_list entities;
};
unordered_map<int, tile_content> hash_map;

for (size_t i = 0; i < 19200; i++) {
   tile_content t;
   t.cost = 1;
   map[i] = t;
}

All this parts of code was compiled in MS VS2010 in debug mode. What I've been seen in my task manager was about 1200 kb of "clean" process, but after filling hash_map it uses 8124 kb of memory. Is it normal behavior of unordered_map? Why so much memory used?

like image 235
Denis Ermolin Avatar asked Feb 21 '12 09:02

Denis Ermolin


People also ask

Does unordered map clear free memory?

Destroying the map will definitely release all of its memory. mymap. rehash(0) might also work. However, just because memory is freed to the implementation (by a call to free ), doesn't mean that the implementation would necessarily release the memory to the operating system.

Which is faster std :: map or std :: unordered_map?

Therefore, the optimized access with std::map is about 20% faster, but the access time of std::unordered_map about 6 times faster.

How much memory does a std::vector use?

So there is no surprise regarding std::vector. It uses 4 bytes to store each 4 byte elements. It is very efficient. However, both std::set and std::unordered_set use nearly an order of magnitude more memory than would be strictly necessary.

Why is unordered_map faster than map?

I used to think that unordered_map is always faster than the map. I googled and then get to know that search time of map is O(log(n)) while search time of unordered_map in O(1) and in worst case its O(n). Internally unordered_map is implemented using Hash Table so how the search time can take O(n) in worst case?


3 Answers

The unordered_map structure is designed to hold large numbers of objects in a way that makes adds, deletes, lookups, and orderless traverses efficient. It's not meant to be memory-efficient for small data structures. To avoid the penalties associated with resizing, it allocates many hash chain heads when it's first created.

like image 127
David Schwartz Avatar answered Sep 20 '22 15:09

David Schwartz


That's roughly 6MB for ~20k objects, so 300 bytes per object. Given the hash table may well be sized to have several times more buckets than current entries, each bucket may itself be a pointer to a list or vector of colliding objects, each heap allocation involved in all of that has probably been rounded up to the nearest power of two, and you've got debug on which may generate some extra bloat, it all sounds about right to me.

Anyway, you're not going to get sympathy for the memory or CPU efficiency of anything in debug build ;-P. Microsoft can inject any slop they like in there, and the user has no right of expectations around performance. If you find it's bad in an optimised build, then you've got something to talk about.

More generally, how it scales with size() is very important, but it's entirely legitimate to wonder how a program would go with a huge number of relatively small unordered maps. Worth noting that below a certain size() even brute force searches in a vector, binary searches in a sorted vector, or a binary tree may out-perform an unordered map, as well as being more memory efficient.

like image 22
Tony Delroy Avatar answered Sep 20 '22 15:09

Tony Delroy


This doesn't necessarily mean that the hash map uses so much memory, but that the process has requested that much memory from the OS.

This memory is then used to satisfy malloc/new requests by the program. Some (or most, I am not sure about this) memory allocators require more memory from the OS than needed at that point in time for efficiency.

To know how much memory is used by the unordered_map I would use a memory profiler like perftools.

like image 44
dmeister Avatar answered Sep 21 '22 15:09

dmeister