3 ms·
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 performan
by encoderer 14y ago
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 14y ago> 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 14y agoNot 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 14y agoI'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.