2 ms·
That sounds like an architectural change, not a problem with PHP's runtime. It's quite possible that the solution to your particular problem can be better expr
by mechanical_fish 17y ago
That sounds like an architectural change, not a problem with PHP's runtime.
It's quite possible that the solution to your particular problem can be better expressed in another language than PHP, or will run faster under a different language's runtime. This doesn't mean that PHP "is slow". It might mean that your problem is an imperfect fit for a PHP-based architecture at your particular scale.
- prodigal_erik 17y agoWe have made architectural changes, but not that day. We literally had a drop-in replacement that did the same work but sustained 5x the request volume before saturating on the same machines, with the rest of the datacenter unchanged. (The async client was merely for latency, not throughput.) I don't believe any PHP runtime can ever be the fastest solution for a problem. The language requires runtime type checks and coercions inside the operators and builtin functions, both keyed and ordered access to every collection, ad hoc creation and destruction of variable bindings by name, and dynamically switching to reference semantics for any existing value. Each of these imposes a cost on passing arguments and evaluating expressions, and I didn't find any of them paid off by making code much simpler.