I am working on a low latency application which needs to be highly efficient all the time.
I need to lookup some index based on string, so I am using c++ unordered_map. Constraints: -Only insertions and lookups, no removals -key is string, value is int -Expecting no more than 1 million entries to be added to unordered_map
I am setting the unordered_map reserve to 1 million, Is this good or should I reserve by an order of some % more than expected entries to avoid rehashing? Can I set it to 1million or should I set to a large prime number close to 1million or some 2 power.
I am using default string hash function in c++ std lib which happens to be murmur2. My keys are between - 25 to 50 characters and all are unique keys containing numbers, upper case english alphabet and _ characters. Would this hash function suffice to distribute keys evenly or do I need to supply a better hash function to the unordered_map?
Would the unordered_map allocate space for 1 million key, value pairs and also an array of size 1 million when i call reserve or at reserve only the array of that size gets created and the key,value pairs gets allocated dynamically on insertion?
How much drag would be the dynamic allocation of key,value pairs on the heap on insertion? Especially since this is a big hash table with many entries.
For performance reasons, would it be good idea to implement my own hash table with memory pre-allocated for 1 million entries on stack or during init, or the above optimizations of unordered_map is close enough?
Is there a way to allocate the memory in advance for expected number of entries in unorderd_map in advance to avoid dynamic allocation on insertion?