[encoderer]

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.

[Firehed]

> 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.

[encoderer]

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?

[Firehed]

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.