3 ms·

> "it's really hard to do it well" More importantly, there are a lot of tradeoffs. Virtually every language offers a hash map. You can roll your own to outper

> "it's really hard to do it well" More importantly, there are a lot of tradeoffs. Virtually every language offers a hash map. You can roll your own to outperform in an individual circumstance, the default works pretty well. You can't really do that with a graph. Maybe if you offered a bunch of graph types. --- PS. Bit of trivia: Java's HashMap is a bit different from almost every other language in that it lets you tune the load factor.

sltkr 3y ago
> Java's HashMap is a bit different from almost every other language in that it lets you tune the load factor. I'm not sure that's particularly unusual. For example, C++ supports this too: https://en.cppreference.com/w/cpp/container/unordered_map/max_load_factor https://en.cppreference.com/w/cpp/container/unordered_map/ma...
- paulddraper 3y ago
  til thanks. (And Java doesn't let you change after construction.)
adastra22 3y ago
> You can't really do that with a graph. Maybe if you offered a bunch of graph types. And so why isn't this the solution? Most languages support both hash map (fast lookup) and balanced tree (ordered entries) primitives, even though they both implement the "associative map" container type. Can't we have 2, 3, 5, or even 8 different graph types?
- masklinn 3y ago
  > Can't we have 2, 3, 5, or even 8 different graph types? That’s what graph libraries do, look at petgraph. You’ve got a bunch of graph implementations, and a bunch of algorithms over them.
karmakaze 3y ago
It's also different in that each hash bucket can use a Red-Black tree when there's many entries.
swiftcoder 3y ago
It's also a bit different in that every insertion entails at least one allocation, and every lookup entails pointer-chasing through at least 3 dereferences. Java's lack of proper value types really kneecaps their hashmap implementation in many practical performance scenarios...
eru 3y ago
> You can't really do that with a graph. Why not? Relations model graphs really well, and you could have a relation datastructure in your language (or its standard library).

sltkr 3y ago

> Java's HashMap is a bit different from almost every other language in that it lets you tune the load factor. I'm not sure that's particularly unusual. For example, C++ supports this too: https://en.cppreference.com/w/cpp/container/unordered_map/max_load_factor https://en.cppreference.com/w/cpp/container/unordered_map/ma...

paulddraper 3y ago
til thanks. (And Java doesn't let you change after construction.)

adastra22 3y ago

> You can't really do that with a graph. Maybe if you offered a bunch of graph types. And so why isn't this the solution? Most languages support both hash map (fast lookup) and balanced tree (ordered entries) primitives, even though they both implement the "associative map" container type. Can't we have 2, 3, 5, or even 8 different graph types?

masklinn 3y ago
> Can't we have 2, 3, 5, or even 8 different graph types? That’s what graph libraries do, look at petgraph. You’ve got a bunch of graph implementations, and a bunch of algorithms over them.

karmakaze 3y ago

It's also different in that each hash bucket can use a Red-Black tree when there's many entries.

swiftcoder 3y ago

It's also a bit different in that every insertion entails at least one allocation, and every lookup entails pointer-chasing through at least 3 dereferences. Java's lack of proper value types really kneecaps their hashmap implementation in many practical performance scenarios...

eru 3y ago

> You can't really do that with a graph. Why not? Relations model graphs really well, and you could have a relation datastructure in your language (or its standard library).