SPACE OR TIME?
Well, it’s not literally ‘SPACE’ or ‘TIME.’
I wanted to share my views on ‘SPACE COMPLEXITY’ vs ‘TIME COMPLEXITY.’ At first, I didn’t really want to choose any side, but then I started to research both of these topics, and what I came to understand is totally unexpected…
Time Complexity
Here’s the thing that got me thinking in the first place — you can always buy extra space. Need more storage? Buy a bigger hard drive. Running out of RAM? Upgrade it. Cloud storage full? Pay for the next tier. Space, at the end of the day, is a commodity. Someone, somewhere, will sell you more of it.
But you cannot buy time. Not really. You can pay someone to do your laundry, pay for a cab instead of walking, order food instead of cooking — but notice what’s actually happening there. You’re not buying time. You’re paying someone else to spend THEIR time so you don’t have to spend yours. Your own clock keeps ticking, completely unaffected by your bank balance. No amount of money buys you a 25th hour in the day. No amount of money buys back the hour you already spent.
AH HAH. Caught you.
I caught myself thinking money could buy time, and it can’t. Not even a little. And that’s exactly why I started leaning toward Time Complexity.
Because the thing you cannot buy is, by definition, the thing you cannot afford to waste. You can free up space — clear a cache, delete a file, refactor a data structure, and suddenly you have room again. But you can never get back the milliseconds your program already spent computing something. Space is recoverable, replaceable, purchasable. Time is not. And in a world where everything is a race — loading screens, API response times, “why is this website taking 3 seconds to load” rage-quits — the resource that can never be bought back or topped up feels like the one that actually matters.
So yeah. If you’re holding a gun to my head and asking me to pick a side, I’m leaning Time Complexity.
Get Utkarsh_Zagade’s stories in your inbox
Join Medium for free to get updates from this writer.
Space Complexity
But here’s where it gets messy — and honestly, where the “totally unexpected” part of this whole thing actually shows up.
Because the moment I lean toward Time, I run into cases where that opinion falls apart immediately. Ask anyone who’s had their app crash from an Out Of Memory error on a low-end phone whether time complexity was the thing that mattered in that moment. It wasn’t. The app didn’t get to be slow — it just died. No time to even be inefficient. Space complexity didn’t lose that argument, it ended it before Time Complexity even showed up.
Same story with embedded systems, with large-scale services processing millions of requests, with anything running on hardware that doesn’t have RAM to spare. In those worlds, space isn’t a secondary concern you optimize after you’ve nailed speed — it’s the wall you hit first.
So really, the “win” I gave Time Complexity in the last section wasn’t universal. It was circumstantial. It only “won” in the specific frame I was thinking in — user-facing speed, things where slow is annoying but survivable.
So… which one actually wins?
Neither. And that’s the unexpected part — not some clever twist ending, just the boring, honest answer that I didn’t want to accept when I started writing this.
Time complexity matters more when speed is the thing your user feels first. Space complexity matters more when your program can’t even survive to be slow. Neither one is universally “more important” — they’re both just different currencies of the same broke system, and which one you spend more carefully depends entirely on where you’re standing when you have to pay.
I went into this trying to pick a side. I came out with a tradeoff instead. Turns out that’s usually how it goes with complexity—the moment you think you’ve found the winner, you’ve just found the specific circumstance where it happens to be true.
Anyway.
Aight, have to brew some tea now.
