PHP 7.3 Performance Benchmarks Are Looking Good Days Ahead Of Its Release

[phoronix]

Phoronix: PHP 7.3 Performance Benchmarks Are Looking Good Days Ahead Of Its Release

Released on Thursday was PHP 7.3 RC6 as the last planned pre-release for the upcoming PHP 7.3. Here are some benchmarks looking at the PHP 7.3 performance compared to PHP releases going back to the v5.5 series on a Linux server...

http://www.phoronix.com/scan.php?page=news_item&px=PHP-7.3-Performance-Benchmarks

[Danny3]

Wow, PHP developers are doing a great job, congratulations to them!
Now I only wish that XAMPP developers will switch to it soon after release and also add the Xdebug extension for it so can stop compiling it ourselves each time.

[kmare]

I agree, kinda makes you wish these improvements were there a few years ago, but oh well. I'm waiting for https://wiki.php.net/rfc/preload in PHP 7.4 to see what kind of real world improvements we can get out of it.
PHP when used in combination with a properly written framework can actually turn into a not so bad language (I personally like Laravel, but to each their own). Of course many improvements are still needed, but you can get your job done quickly.

[MrEcho]

It is amazing how far PHP has come in the last few years. Some of the old cruft is still there, but thats there to not completely break peoples past work.
If your still using Globals and not Stored Procedures, you should be fired. And I still have mixed feelings of the big frameworks, I think generally they have really helped out, but at the same time its created a lot of developers that dont know what they are doing. Not as bad as Node devs

I think where getting to the point where PHP is fast enough™, and with the new code cache, its going to push it that much more. FFI will be fun to see what comes of that, but it gets into scary security land.

Now just to get everyone off 5.x ....

[eva2000]

looking good, I did my own PHP 7.3 comparison benchmarks and pretty much inline with what your results are seeing https://community.centminmod.com/threads/16090/

[ksec]

As a Ruby user I am envy the improvement coming from PHP. I haven't follow PHP in any details or depth, who is behind the development of PHP compiler? Facebook ? Zend?

[boxie]

It is amazing how far PHP has come in the last few years. Some of the old cruft is still there, but thats there to not completely break peoples past work.
If your still using Globals and not Stored Procedures, you should be fired. And I still have mixed feelings of the big frameworks, I think generally they have really helped out, but at the same time its created a lot of developers that dont know what they are doing. Not as bad as Node devs

I think where getting to the point where PHP is fast enough™, and with the new code cache, its going to push it that much more. FFI will be fun to see what comes of that, but it gets into scary security land.

Now just to get everyone off 5.x ....

Using stored procedures means that you are not using an ORM... pls2be investigating using an ORM - it makes many things in life much easier!

[cen1]

The improvement since PHP 5 is quite amazing to see.

[MrEcho]

Using stored procedures means that you are not using an ORM... pls2be investigating using an ORM - it makes many things in life much easier!

A ORM is not needed for every project, and you dont know how I do my SQL. An ORM is not the end all be all of SQL, there are a lot of edge cases where it just falls apart, or uses too much ram and or is to slow. Does it make things easier, sure, if you dont know what your doing. As someone that has been working with PHP / SQL for almost 20 years now, I know a thing or two. Ive also been a sys admin / engineer for 14+ years. Ive seen what happens when devs use an ORM and have no clue what it does to the SQL server I had to manage. I hand them the SQL statements thats causing all sorts of issues, and they look at me with a blank face... "its the ORM, I dont know how to fix it"
It works very well for simple CRUD operations, but once you get into the real SQL, it falls apart.

On the topic of SQL, Async MySQL/Postgres sounds neat, till you do transactions, or you really need that boolean / object back to continue on to the next function in your script.

[lucrus]

Ive seen what happens when devs use an ORM and have no clue what it does to the SQL server I had to manage. I hand them the SQL statements thats causing all sorts of issues, and they look at me with a blank face... "its the ORM, I dont know how to fix it"
It works very well for simple CRUD operations, but once you get into the real SQL, it falls apart.

First of all, welcome to the twenties.

Second, maybe you've known the wrong developers: sure, they should learn the ORM they are supposed to use and that's the real problem, but entirely replacing ORMs with stored procedures is just a worse problem. Decent ORM frameworks do not produce SQL statements that cause all sort of issues. Usually the cause is a schema design flaw.

Third, basic CRUD is part of the "real SQL" as much as stored procedures are. Moreover, CRUD is usually at least 90% of the total SQL statements of any application. Given the added burden of maintaining stored procedures, it does not make any sense to drop a ORM just for the sake of fearing what could happen outside of the cavern where you live.

Fourth, any decent ORM can use stored procedures, they are not mutually exclusive.

Last but not least, man-hours cost way more than hardware upgrades, and the performance hit is the ONLY reason to prefer stored procedures over a decent ORM. In other words you better keep the stored procedures at the bare minimum that makes your app work at acceptable speed, or YOU risk to get fired, instead of ORM developers.