[barrkel]

> Secondly with any web framework your app will most likely be limited by IO (database, file lookups, networking) before it becomes limited by actual code execution performance.

Latency is additive; it's a sum() operation, not a max() operation. Yes, a large fraction of most web requests get eaten by blocking on IO, but everything on top of that adds up, and small numbers add up surprisingly quickly. And the more you try to be smart about that stuff, whether it's optimizing what you query, do extra caching, try to turn multiple DB roundtrips into a single trip, you often just trade IO time for CPU time (albeit lower). You still care about CPU performance.

[cies]

> Latency is additive; it's a sum() operation, not a max() operation.

This! And you can only discard some components latency when it disappears in the deviation of another components much larger latency. In most PHP (or Ruby/Python/etc for that matter), this is not the case. They add some 10-150ms on top, and often the db calls are <10ms.

Performance does matter, and is hard to improve once you have many KLOC of code in a slow language. Hence FB spend big bucks on PHP performance improvements.

[mschuster91]

> and often the db calls are <10ms

Most are <10ms. Those nasty few ones with 100+ms (or sometimes 10+s!) are where the best money is spent optimizing. However good query/db schema optimization is a skill many developers do not possess... which is why a good DBA is worth his weight in gold.