Large web apps do often spend a lot of time manipulating strings and arrays in memory. It's absolutely true and I've seen it myself several times -- a performance penalty that is measurable and noticeable to users.

But that pales in comparison to the overhead of a Database call, or even a call to Redis or Memcached.

I've read (from sources I trust) that a database call on a modern stack like .Net or JVM is 4 orders of magnitude slower than a local method call. Think about that. So if the time you spend brushing your teeth is a local method call, the entire next day is a database query.

I can't remember the source here but the information is available with a few minutes of coding or googling.

And to the caching point -- having data cached locally in memory is great, but you can't trust that.

> And to the caching point -- having data cached locally in memory is great, but you can't trust that.

You can if you design around handling a possibly-stale cache.

Not really. There is no system that ever has had an always-fresh cache.

Are you disputing the premise or just disagreeing for the sake of it?

I'm saying that having a stale cache won't be a problem for an application that is designed around the fact that you will occasionally have stale data.

Database access latency will always trump any language design issues, except in extreme cases. This article does make some of those cases obvious, especially since they are easily-overlooked programming mistakes.

Database access latency will always be an important factor of _latency_ .

That doesn't prevent anyone from coding stuff that requires 20 times less application servers while using the same amount of database (+caching) servers.

The very idea that because the DB call takes a while to complete, we can waste even more CPU cycles is a complete misunderstanding of real world use cases.

But then, the very use of PHP means that you don't give a shit about execution time or server costs at all.