[Question] Can I assume time-complexity of O(1) for read / write? about parallel-hashmap

[greg7mdp]

@wbrickner yes you are correct inserting an element or lookup is done in constant time, or O(1), in the phmap containers.

• For lookup this is always the case.
• For insertion, this is the case as well, except for the rare case where the insertion causes the table to resize, in which case this insertion will be O(n).

This is assuming that the hash function provided has a reasonable distribution. If most keys to be inserted in the hash map do hash to just a few different values, then there are going to be a lot of collisions and time complexity will be O(n).

[greg7mdp]

Closing the issue, but feel free to ask more questions of clarifications if needed. Thanks!

[wbrickner]

I use built-in hash functions on unsigned long keys, which are always monotonically ascending, and should have some gaps (or they can be all counting up with no gaps, neither can be assumed). I've assumed the built-in hash function will perform well under these conditions. In your estimation is that correct?

Also, what is the time complexity for .clear()? In std::unordered_map, it's O(n).
Is this still the case with the phmap containers, or has something clever been done?

Is there any table which describes the time complexity of all the methods? I know they're not necessarily the same as std::unordered_map, and I like to keep a note of time complexity of all methods on my classes, many of which now depend on the complexity of the phmap containers.

Thank you very much for your help!

[greg7mdp]

I use built-in hash functions on unsigned long keys, which are always monotonically ascending, and should have some gaps (or they can be all counting up with no gaps, neither can be assumed). I've assumed the built-in hash function will perform well under these conditions. In your estimation is that correct?

yes, that is correct. Whether there are gaps or not should not make a difference.

Also, what is the time complexity for .clear()? In std::unordered_map, it's O(n).
Is this still the case with the phmap containers, or has something clever been done?

Indeed something smart is being done if the capacity is > 127. In that case, the memory array is simply deallocated, so it will be O(1) for types with no destructors. Of course, if the types stored in the hash map have non-empty destructors, it will be O(n) since all destructors have to be executed.

Is there any table which describes the time complexity of all the methods? I know they're not necessarily the same as std::unordered_map, and I like to keep a note of time complexity of all methods on my classes, many of which now depend on the complexity of the phmap containers.

I don't have such a table at this time. Is there one for std::unordered_map? Besides the .clear() optimization I mentioned, I don't think it would be different from std::unordered_map.

[wbrickner]

There's not a centralized table AFAIK, but all online documentation for the STL containers provide theoretical time complexity for all methods.

If I want to remove all keys, then repopulate the table with a nearly identical set of keys with all new values, is there a non-standard method which would be more efficient than the complete deallocate-reallocate pattern? Maybe it's not an issue, idk.

Also I'm no C++ expert, are memory deallocations generally O(1)? I assumed all large memory de/allocations would resemble O(n) behavior?

Thanks!

[greg7mdp]

If I want to remove all keys, then repopulate the table with a nearly identical set of keys with all new values, is there a non-standard method which would be more efficient than the complete deallocate-reallocate pattern? Maybe it's not an issue, idk.

There is no non-standard method for this. I would do clear(), reserve(expected_size), and then insert new items. Should be very efficient, and it is hard to imagine some non--standard method which would be faster.

Also I'm no C++ expert, are memory deallocations generally O(1)?

yes, they are, unless you are deallocating an array of C++ objects which have destructors, But deallocating an array of basic types (int, long, etc...) or objects with empty destructors is O(1).

[greg7mdp]

I had a quick look at the complexities listed for std::unordered_map and I do believe that the one for phmap will be the same (modulo the clear() optimization I already mentioned).