5 ms·

You should reach for the best tool for the job instead of giving job-specific reasons for your general choice. Without going into detail explaining how your bul

You should reach for the best tool for the job instead of giving job-specific reasons for your general choice. Without going into detail explaining how your bullets either don't apply to most uses, prematurely code for a future case that may not exist, dismiss performance, reference other languages as if language implementation is not a factor in the choice, etc... suffice to say they both have their place and in general you probably shouldn't reach for an ordered map over a unordered one without reason. I.e. it shouldn't be your default choice in most languages and it'd be bad advice to give other programmers.

naniwaduni 7y ago
The problem with choosing "the best tool for the job" for every job is that now you have a lot more unknown unknowns and they don't generalize when you find them.
ummonk 7y ago
An ordered map is much better as a default simply because it can do everything that an unordered map can. Choosing to use an unordered map instead is a premature optimization that is nearly always unnecessary.
- GeneralMayhem 7y ago
  That argument works both ways, though. An unordered map has the narrower interface and generally better performance, so it's much better as the default. Choosing to use an ordered map instead is YAGNI interface bloat that is nearly always unnecessary.
  - deleted 7y ago
    [deleted]
- mantap 7y ago
  IMO, premature optimization doesn't apply to cases where you are making general decisions about policy or defaults, otherwise you can get into a "death by a thousand cuts" situation where none of your functions are slow individually but the whole program is slow (i.e. big overheads). To me, premature optimization means don't optimize a specific function unless you know it is slow. I'd also say that premature optimization doesn't apply in cases where both alternatives are equally easy to write.
  - mlyle 7y ago
    On the other hand, if you pick a TreeMap--- odds are it will be a non-issue either way. If it does show up on your profiles, it's easy to reconsider and say "I don't think I'll ever access this in order, after all..." and change it and see if you see a benefit.
  - JadeNB 7y ago
    > I'd also say that premature optimization doesn't apply in cases where both alternatives are equally easy to write. I think that premature optimisation applies not only to ease of writing, but even more to ease of debugging.
  - unethical_ban 7y ago
    Prematurely optimizing for death by a thousand cuts is what you're proposing.
- kodablah 7y ago
  Premature optimization concerns effort. We do a lot of things when writing code that could be considered premature optimization by your vague definition. By this definition too, staying in Java land, I should probably not instantiate my ArrayList or HashMap with a capacity even if I know it...technically premature optimization. All else equal wrt simplicity, choose the highest performing option that contains the features you need. Dogmatic premature optimization rules are unhelpful. We can apply reasonable thinking, and we should.
  - naasking 7y ago
    > Premature optimization concerns effort And the OP is correct that writing a correct comparison function needed for an ordered map is easier than writing a correct hash function that is properly distributed. So the ordered map is lower effort for that reason alone, although the other properties the OP lists also produce valid reductions of effort.
loeg 7y ago
Especially when an ordered map is backed by a binary tree (TreeMap), which is the worst data structure. Btree ordered maps good, hash tables good (if point queries are sufficient); binary trees have terrible cache locality.
- kccqzy 7y ago
  Cache locality issues can be fixed by using a good allocator (or a good compacting GC).
  - AstralStorm 7y ago
    How can an allocator optimize the layout of a dynamically sized structure that's being changed without compacting? Now, compacting is an O(n) memory move plus additional calculation to figure out optimal-ish layout. (Can be amortized, but it's same as amortizing hash table resizing. Optimal layout cannot be decided without profiling, and that's expensive.)

naniwaduni 7y ago

The problem with choosing "the best tool for the job" for every job is that now you have a lot more unknown unknowns and they don't generalize when you find them.

ummonk 7y ago

An ordered map is much better as a default simply because it can do everything that an unordered map can. Choosing to use an unordered map instead is a premature optimization that is nearly always unnecessary.

GeneralMayhem 7y ago
That argument works both ways, though. An unordered map has the narrower interface and generally better performance, so it's much better as the default. Choosing to use an ordered map instead is YAGNI interface bloat that is nearly always unnecessary.
- deleted 7y ago
  [deleted]
mantap 7y ago
IMO, premature optimization doesn't apply to cases where you are making general decisions about policy or defaults, otherwise you can get into a "death by a thousand cuts" situation where none of your functions are slow individually but the whole program is slow (i.e. big overheads). To me, premature optimization means don't optimize a specific function unless you know it is slow. I'd also say that premature optimization doesn't apply in cases where both alternatives are equally easy to write.
- mlyle 7y ago
  On the other hand, if you pick a TreeMap--- odds are it will be a non-issue either way. If it does show up on your profiles, it's easy to reconsider and say "I don't think I'll ever access this in order, after all..." and change it and see if you see a benefit.
- JadeNB 7y ago
  > I'd also say that premature optimization doesn't apply in cases where both alternatives are equally easy to write. I think that premature optimisation applies not only to ease of writing, but even more to ease of debugging.
- unethical_ban 7y ago
  Prematurely optimizing for death by a thousand cuts is what you're proposing.
kodablah 7y ago
Premature optimization concerns effort. We do a lot of things when writing code that could be considered premature optimization by your vague definition. By this definition too, staying in Java land, I should probably not instantiate my ArrayList or HashMap with a capacity even if I know it...technically premature optimization. All else equal wrt simplicity, choose the highest performing option that contains the features you need. Dogmatic premature optimization rules are unhelpful. We can apply reasonable thinking, and we should.
- naasking 7y ago
  > Premature optimization concerns effort And the OP is correct that writing a correct comparison function needed for an ordered map is easier than writing a correct hash function that is properly distributed. So the ordered map is lower effort for that reason alone, although the other properties the OP lists also produce valid reductions of effort.

loeg 7y ago

Especially when an ordered map is backed by a binary tree (TreeMap), which is the worst data structure. Btree ordered maps good, hash tables good (if point queries are sufficient); binary trees have terrible cache locality.

kccqzy 7y ago
Cache locality issues can be fixed by using a good allocator (or a good compacting GC).
- AstralStorm 7y ago
  How can an allocator optimize the layout of a dynamically sized structure that's being changed without compacting? Now, compacting is an O(n) memory move plus additional calculation to figure out optimal-ish layout. (Can be amortized, but it's same as amortizing hash table resizing. Optimal layout cannot be decided without profiling, and that's expensive.)