3 ms·

>I would argue that data fetching from DBs or caches will be the majority of execution time. People keep saying that, and I would like to see some numbers for

>I would argue that data fetching from DBs or caches will be the majority of execution time. People keep saying that, and I would like to see some numbers for that also. The DB dataset could be already cached in memory, for example.

ihsw 14y ago
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.
- ludovicurbain 14y ago
  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.
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 ago
    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 14y ago
      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.

ihsw 14y ago

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.

ludovicurbain 14y ago
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.

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 ago
  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 14y ago
    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.