This all presupposes that reducing big oh increases code complexity. In my experience, that's simply not true. Unless you are writing C without libraries, you are almost certainly dealing with a language rich in datastructures that easily reduce big oh notation while clearly communicating intent.
A dictionary will generally beat storing values as key/value in a list, de-duplicating and linearly searching on the key. If you don't believe that, then go ahead and pollute your codebase with List<Pair<Key, Value>>. See how fast that will be.
Heck, go ahead and use and manage a Pair<Key, Value>[]. After all, can't prematurely optimize by using a data structure that automatically manages growth.
Maybe just store everything as a giant String. You can just keep concatenating new values and searching for others in it. Why let those pesky types get in the way of easy to understand string manipulation and regexs? After all, don't prematurely optimize.
Hey, perhaps you should always just bundle and distribute perl with your applications and fork off new instances of perl since it has such nice regex capabilities. After all, don't prematurely optimize.
Have you measured that performance? Halt before you say it's a bad idea, because obviously we need to profile everything and make sure that starting new perl processes are actually slow. Can't be prematurely optimizing.
> Unless you are writing C without libraries, you are almost certainly dealing with a language rich in datastructures that easily reduce big oh notation while clearly communicating intent.
Just to name it, I’m increasingly finding myself in positions where off the shelf data structures don’t solve the problems I have. I’m writing a novel CRDT for collaborative text editing. Some data structures I’ve needed:
- A generic run-length encoded vector that I can append to and binary search.
- A generic run-length encoded b-tree which indexes by the current total length of the sub tree.
- A gap buffer which stores run-length encoded items. Items can be split by a freshly inserted item. And each item has an array of states with a size set when the data structure is created. I might end up moving to a skip list of gap buffers.
Needing a lot of custom data structures is pretty rare. And if I was forced to, I could probably cobble together something that would perform well enough on top of the built in container classes. But doing it all custom is fun. My performance results justify the approach - my system performs orders of magnitude better than any other implementation.
> A dictionary will generally beat storing values as key/value in a list, de-duplicating and linearly searching on the key. If you don't believe that
I don't believe that, although "generally" is doing heavy lifting here. It depends on the key, value, number of kv, how good the hash algo is, etc. Yeah, standard impls are pretty good nowadays. If you don't want to bother understanding the problem space fully (which like you said is fine, otherwise we'd get nowhere), use a standard tool to solve the problem.
So yes, by all means use a hash map if it makes it easier to read/reason about. Hash maps after all are a common tool for this. Just don't start with the big-O crap.
A dictionary will generally beat storing values as key/value in a list, de-duplicating and linearly searching on the key. If you don't believe that, then go ahead and pollute your codebase with List<Pair<Key, Value>>. See how fast that will be.
Heck, go ahead and use and manage a Pair<Key, Value>[]. After all, can't prematurely optimize by using a data structure that automatically manages growth.
Maybe just store everything as a giant String. You can just keep concatenating new values and searching for others in it. Why let those pesky types get in the way of easy to understand string manipulation and regexs? After all, don't prematurely optimize.
Hey, perhaps you should always just bundle and distribute perl with your applications and fork off new instances of perl since it has such nice regex capabilities. After all, don't prematurely optimize.
Have you measured that performance? Halt before you say it's a bad idea, because obviously we need to profile everything and make sure that starting new perl processes are actually slow. Can't be prematurely optimizing.