3 ms·

Unfortunately, judging from my own (very limited) speed tests, that result simply means that it is en par with PHP 5.5. PHP 5.6 is not only not finished yet -

by skore 12y ago

Unfortunately, judging from my own (very limited) speed tests, that result simply means that it is en par with PHP 5.5. PHP 5.6 is not only not finished yet - it is, in my experience, also the worst performing version you could choose. Not sure that's a good idea.

ck2 12y ago
Perhaps you are configuring them differently. I have a test box with all recent 5.x versions installed. 1000 WP front pages, identical php build configuration: 5.4 28.081s, 28.673s, 29.458s, 28.017s 5.5 26.402s, 26.448s, 26.522s, 26.523s 5.6 25.774s, 25.643s, 25.752s, 25.670s NG 15.083s, 15.100s, 15.052s, 15.066s
- nikic 12y ago
  Common mistakes: Testing with xdebug enabled in one version or testing with opcache enabled in only one version.
  - skore 12y ago
    I was testing with: PHP 5.6.0beta4 (cli) (built: Jun 12 2014 14:13:53) Zend Engine v2.6.0-dev, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans vs. PHP 5.5.13 (cli) (built: Jun 12 2014 13:54:54) Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans ...but, as I said - this is with very limited testing, basically just on Travis (which goes up and down in speed all day, but the difference between versions is pretty steady).
    - ck2 12y ago
      Note RC3 is about to ship so maybe try that. Is xdebug load neutral? Maybe you need to skip loading that during testing, you wouldn't use it during production?
      - skore 12y ago
        The "limit" of my test is that it's sort of a worst-case scenario - Travis does have a couple of things set up that you may not find in the wild, but the entire purpose is to get speed ratings on a purposefully crappy system.

by skore 12y ago

ck2 12y ago

Perhaps you are configuring them differently. I have a test box with all recent 5.x versions installed. 1000 WP front pages, identical php build configuration: 5.4 28.081s, 28.673s, 29.458s, 28.017s 5.5 26.402s, 26.448s, 26.522s, 26.523s 5.6 25.774s, 25.643s, 25.752s, 25.670s NG 15.083s, 15.100s, 15.052s, 15.066s

nikic 12y ago
Common mistakes: Testing with xdebug enabled in one version or testing with opcache enabled in only one version.
- skore 12y ago
  I was testing with: PHP 5.6.0beta4 (cli) (built: Jun 12 2014 14:13:53) Zend Engine v2.6.0-dev, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans vs. PHP 5.5.13 (cli) (built: Jun 12 2014 13:54:54) Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans ...but, as I said - this is with very limited testing, basically just on Travis (which goes up and down in speed all day, but the difference between versions is pretty steady).
  - ck2 12y ago
    Note RC3 is about to ship so maybe try that. Is xdebug load neutral? Maybe you need to skip loading that during testing, you wouldn't use it during production?
    - skore 12y ago
      The "limit" of my test is that it's sort of a worst-case scenario - Travis does have a couple of things set up that you may not find in the wild, but the entire purpose is to get speed ratings on a purposefully crappy system.