4 ms·

Is there anymore major performance improvements left to make to PHP or is everything else just dimishing returns? No disrespect to the huge amount of work the

Is there anymore major performance improvements left to make to PHP or is everything else just dimishing returns? No disrespect to the huge amount of work the PHP team has already completed, they should be praised. Just curious to know if we can expect anymore major performance improvements like we saw from v5 to v7. EDIT: After further searching, appears PHP 8 will have some sort of JIT (with the hope that it'll continue to bring significant perf improvements. More info at http://news.php.net/php.internals/95531 http://news.php.net/php.internals/95531

progforlyfe 10y ago
Yes, the next major performance improvements will come from a JIT style machine, similar to what HHVM does.
- tiffanyh 10y ago
  I'm confused, so PHP 7 today does not have a JIT yet its performance is already on-par with HHVM (which has a JIT). Are you then suggesting that PHP 8 (with a JIT) will be significantly faster than HHVM?
  - TazeTSchnitzel 10y ago
    Not necessarily. It may mean that a lot of HHVM's performance improvements were not related to JIT.
- otto_ortega 10y ago
  I'm also confused. Php 7 has Opcache, which according to the documentation: "OPcache improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request." How would JIT features come into play with it?
  - deleted 10y ago
    [deleted]
  - TazeTSchnitzel 10y ago
    Precompiled here means bytecode, not machine code. OPcache is similar to, say, Python's .pyc files.
nikic 10y ago
Our perf work in the 7.1 cycle hasn't shown any significant gains on real applications (we have some improvements for computationally intensive code -- like arithmetic inside tight loops). Whether or not the JIT will bring a major improvement for applications is not yet clear, but the hope is obviously there.
- boulos 10y ago
  Right, having done this myself long ago, much of the performance improvement comes from just raw C-code in the runtime. Making less string copies, etc. are a big deal, especially on real programs. That's much of what you've seen in the first set of PHP 7 improvements. Taking PHP from a bytecode interpreter to generated x86 will mean that in places where you don't end up "hopping out", you should see closer to C-code like performance (the same is true for JavaScript, Python, etc.). Unlike a few years ago though, PHP7's scalar type hints and other slight tweaks (made on purpose!) should make this an even easier task than it was for say PHP 5.4. Type inference is incredibly effective, and in practice (see Paul Biggar's excellent thesis on this) there really isn't that much polymorphism in PHP programs. Parameters to functions usually have one maybe two types or they're actually polymorphic and see 15+ variations. This is just the nature of what you're able to reason about ("Can I really handle this being an int, float, bool, string, array, function callback, or arbitrary class here? Of course not..."). That said, once you get the two of them working really well together (eliminating friction at calling from the generated machine code for the language back into the runtime), you see additional benefits even on real programs. It's too bad they only report what the API endpoint did, that's relatively easy! (The full dashboard load was much more complex, with tons of crazy class loading and JSON serialization/deserialization, lots of Thrift RPCs, and plenty of memcache). Source: I've run the Tumblr dashboard in production briefly on a system with a JIT-based runtime ;)

progforlyfe 10y ago

Yes, the next major performance improvements will come from a JIT style machine, similar to what HHVM does.

tiffanyh 10y ago
I'm confused, so PHP 7 today does not have a JIT yet its performance is already on-par with HHVM (which has a JIT). Are you then suggesting that PHP 8 (with a JIT) will be significantly faster than HHVM?
- TazeTSchnitzel 10y ago
  Not necessarily. It may mean that a lot of HHVM's performance improvements were not related to JIT.
otto_ortega 10y ago
I'm also confused. Php 7 has Opcache, which according to the documentation: "OPcache improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request." How would JIT features come into play with it?
- deleted 10y ago
  [deleted]
- TazeTSchnitzel 10y ago
  Precompiled here means bytecode, not machine code. OPcache is similar to, say, Python's .pyc files.

nikic 10y ago

Our perf work in the 7.1 cycle hasn't shown any significant gains on real applications (we have some improvements for computationally intensive code -- like arithmetic inside tight loops). Whether or not the JIT will bring a major improvement for applications is not yet clear, but the hope is obviously there.

boulos 10y ago
Right, having done this myself long ago, much of the performance improvement comes from just raw C-code in the runtime. Making less string copies, etc. are a big deal, especially on real programs. That's much of what you've seen in the first set of PHP 7 improvements. Taking PHP from a bytecode interpreter to generated x86 will mean that in places where you don't end up "hopping out", you should see closer to C-code like performance (the same is true for JavaScript, Python, etc.). Unlike a few years ago though, PHP7's scalar type hints and other slight tweaks (made on purpose!) should make this an even easier task than it was for say PHP 5.4. Type inference is incredibly effective, and in practice (see Paul Biggar's excellent thesis on this) there really isn't that much polymorphism in PHP programs. Parameters to functions usually have one maybe two types or they're actually polymorphic and see 15+ variations. This is just the nature of what you're able to reason about ("Can I really handle this being an int, float, bool, string, array, function callback, or arbitrary class here? Of course not..."). That said, once you get the two of them working really well together (eliminating friction at calling from the generated machine code for the language back into the runtime), you see additional benefits even on real programs. It's too bad they only report what the API endpoint did, that's relatively easy! (The full dashboard load was much more complex, with tons of crazy class loading and JSON serialization/deserialization, lots of Thrift RPCs, and plenty of memcache). Source: I've run the Tumblr dashboard in production briefly on a system with a JIT-based runtime ;)