My personal prior belief is that PHP is about 20 times slower than “the maximum”, an imaginary ideal for efficient code which is probably only achieved by spending far too much time far too close to the metal. The maximum comes with a “2x barrier” where interpreted languages with a managed runtime can only come within about a factor of 2 of the maximum. In the post, the author claims a 16-fold improvement from PHP to Haskell while implementing the same functionality, which would put GHC Haskell below the 2x barrier. This is fairly impressive and worth highlighting.
Of course, we can’t discount other factors, such as the fact that rewrites can easily obtain performance improvements simply by being written by a team who understands the problem domain better on each iteration.
Author of OP here. There’s a million benchmarks out there, such as the TechEmpower Framework Benchmarks, that try to make fair comparisons where the exact same problem is solved by different languages/frameworks. While they are valuable in some ways, there are plenty of people that point at them and say “benchmarks like this are meaningless since they don’t reflect real world situations”. So what I did in my post is describe a comparison based on a real world situation.
My a comparison based on the switch from a production system built in PHP to a continuation of the same system being built in Haskell. I’ll add that when we did this, we did nothing special as far as performance goes—we just started implementing all of our new functionality in Haskell rather than PHP. The result was that operating the new stuff was 1/16th the cost of operating the old stuff. Feel free to waive this away as unremarkable or irrelevant, but I don’t think it is.
Proceeds to benchmark Haskell against PHP
My personal prior belief is that PHP is about 20 times slower than “the maximum”, an imaginary ideal for efficient code which is probably only achieved by spending far too much time far too close to the metal. The maximum comes with a “2x barrier” where interpreted languages with a managed runtime can only come within about a factor of 2 of the maximum. In the post, the author claims a 16-fold improvement from PHP to Haskell while implementing the same functionality, which would put GHC Haskell below the 2x barrier. This is fairly impressive and worth highlighting.
Of course, we can’t discount other factors, such as the fact that rewrites can easily obtain performance improvements simply by being written by a team who understands the problem domain better on each iteration.
Author of OP here. There’s a million benchmarks out there, such as the TechEmpower Framework Benchmarks, that try to make fair comparisons where the exact same problem is solved by different languages/frameworks. While they are valuable in some ways, there are plenty of people that point at them and say “benchmarks like this are meaningless since they don’t reflect real world situations”. So what I did in my post is describe a comparison based on a real world situation.
My a comparison based on the switch from a production system built in PHP to a continuation of the same system being built in Haskell. I’ll add that when we did this, we did nothing special as far as performance goes—we just started implementing all of our new functionality in Haskell rather than PHP. The result was that operating the new stuff was 1/16th the cost of operating the old stuff. Feel free to waive this away as unremarkable or irrelevant, but I don’t think it is.