Big O notation and analysis techniques can apply to both time and space and the same algorithm can have very different Big O approximations between time and spa

Big O notation and analysis techniques can apply to both time and space and the same algorithm can have very different Big O approximations between time and space. For instance, a hash table (dictionary/map) algorithm may give you some nice O(log n) performance in time, but because you need to be able to retrieve the items you store is best case never going to be better than O(n) in space. It's possible to find such algorithms with worst cases nearly as bad as O(n^2) in space overhead (or Omega(n^2) if you prefer Omega-notation to mean "worst case approximation"). They may still be nice O(log n) in algorithm time, but the theoretical "speed" comes at the tradeoff of space utilization. Trade-offs in space of course have practical impacts on time in the real world (between locks, paging, bank switching, bank delays, bandwidth/light speed distance to specific banks, cache prefetch intelligence, and so many more variables, some ancient and some modern and/or language specific). As with everything involving Big O notation: it's a first order approximation. (Literally so, as that's exactly what Big O means, summarize things to the first order in the presumed polynomial equation that describes it time or space [!] complexity.) The exact same analysis process is useful for more than just "number of algorithm steps" (time) and can be useful in examining algorithm space requirements ("number of memory units", say). Also, it's still an approximation to start an analysis and that's rarely where you should stop in your analysis in real life.