Announcement

Collapse
No announcement yet.

Looking At The PHP 8.0 Performance So Far In Early 2020

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Looking At The PHP 8.0 Performance So Far In Early 2020

    Phoronix: Looking At The PHP 8.0 Performance So Far In Early 2020

    With it being a while now since the PHP 7.4 release and the PHP developers continuing to be busy at work on PHP 8.0 as the next major installment of the popular web programming language, here is a fresh look at the performance of PHP 8.0 in its current state -- including when its JIT compiler is enabled -- compared to releases going back to PHP 5.6...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I'm really not looking forward to it since every minor 7.x update has broken compatibility with older code.

    In fact I wish all PHP devs quit and never released a new version ever again, because they constantly break compatibility.

    Comment


    • #3
      Originally posted by czz0 View Post
      I'm really not looking forward to it since every minor 7.x update has broken compatibility with older code.

      In fact I wish all PHP devs quit and never released a new version ever again, because they constantly break compatibility.
      What are you talking about ? If your code is regularly maintained, it should not be a problem. Even with a code from 5.x version, it should be relatively easy to port it.

      Comment


      • #4
        Originally posted by Floux View Post

        What are you talking about ? If your code is regularly maintained, it should not be a problem. Even with a code from 5.x version, it should be relatively easy to port it.
        Not always possible to keep codebases up-to-date 100% of the time, we have PHP 4 lingering in our internal system, and even some .php3 files though those are in features no longer used.

        Comment


        • #5
          Originally posted by czz0 View Post
          I'm really not looking forward to it since every minor 7.x update has broken compatibility with older code.

          In fact I wish all PHP devs quit and never released a new version ever again, because they constantly break compatibility.
          I actually hope they fix the problems with the language, rather than caring about unmaintained code which can be supported through containers.

          Comment


          • #6
            Originally posted by czz0 View Post
            I'm really not looking forward to it since every minor 7.x update has broken compatibility with older code.

            In fact I wish all PHP devs quit and never released a new version ever again, because they constantly break compatibility.
            You're 100% mistaken. They follow semver religiously.

            Comment


            • #7
              Michael Nikita says those JIT results don't look right, see this comment on reddit

              Comment


              • #8
                Originally posted by czz0 View Post
                I'm really not looking forward to it since every minor 7.x update has broken compatibility with older code.

                In fact I wish all PHP devs quit and never released a new version ever again, because they constantly break compatibility.
                How about learning to code properly?

                Comment


                • #9
                  Originally posted by czz0 View Post
                  I'm really not looking forward to it since every minor 7.x update has broken compatibility with older code.
                  In fact I wish all PHP devs quit and never released a new version ever again, because they constantly break compatibility.
                  That's no feature exclusive to PHP, this happens a lot in other languages, too. Being part of some php development we just did work to make our codebase work with php7.4. Before doing that, I went through a RoR project needing maintenance to be able to run with newer Ruby & Rails, and also had to do rework C, python and sone other code to keep them running.

                  Languages are mostly in constant evolution. The truth is: You should worry if no things do change anymore. There is no more evident sign of a dead language, that will vanish, than that. And that will totally kill your codebase and your tools.

                  Comment


                  • #10
                    Originally posted by mzeb View Post

                    Not always possible to keep codebases up-to-date 100% of the time, we have PHP 4 lingering in our internal system, and even some .php3 files though those are in features no longer used.
                    /Triggered

                    There is a difference between not being able to keep a code base up to date and what you just posted. Your still running PHP 4 code internally = Your company never bothered to upgrade to PHP5 ... All the PHP5.X releases, PHP7.0 or all the PHP7.X releases.

                    That is just pure laziness of your company for the last 20!!! years!!!. Most of the code, even from PHP4 can be fairly easily upgraded in a few hours time. Worst case your looking at a week if its a massive code base. If its that, then your running some important data and not just some coffeemaker scripts. And their is no excuse to not drag management down to a table.

                    Your biggest issue is stuff like mysql API changes and a lot of global / other bad practices ( and your not even using prepared statements ). Almost 80% of the work is search/replaces and pressing the button X number of times.

                    Even for Internal code, its best to keep your code up to date because you never know if somebody by accident exposes your internal pages to the external world. Or having a bad employee who decides before he leaves, to sabotage your systems. Having such open vulnerabilities is just asking for somebody to misuse them.

                    Even going from PHP5 to PHP7 can be solved with upgrade script that do automated search replaces... Or just install the demo version of PHPstorm, import the code, set your project to PHP7 and PHPstorm will identify all the bad / smelly code that is not valid anymore. And search replace most of it.

                    It sounds to me that your company needs a internal audit because if your running that old code, it am betting there are more bodies in the cabinet. And the excuse of "we have never been hurt", that sounds great until it happens. Seen companies with older wordpress sites where developers ended up spending weeks to "fix" all the malware code, going over databases etc because "nothing will go wrong, focus on coding more. Maintenance does not earn us moooooonieeee". Companies never learn until it cost them 10.000's of dollars ( or their entire company when the clients jump ship ).

                    Remember the old saying: Sht runs downhill. Even if you tell management your still running 20 year old insecure code ( and you betcha that PHP4 code will be insecure ), IF something goes wrong, its not management their heads on the block but the IT guys down the line. And management will get selective amnesia and will be all "but it was your job to tell us these things. You told us? You never said its that dangerous. You did? No, if you did i will remember it. Its your fault!" ...

                    So chop chop, time to request a meeting with the higher ups and get this mess fixed before it fixes you

                    Comment

                    Working...
                    X