PHP 7.3 Performance Benchmarks Are Looking Good Days Ahead Of Its Release (phoronix.com) 91
PHP 7.3 RC6 was released earlier this week. Phoronix ran some benchmarks and compared the performance of v7.3 RC6 with releases going back to the v5.5 series. From the story: I ran some fresh benchmarks over the past day on PHP 5.5.38, PHP 5.6.38, PHP 7.0.32, PHP 7.1.24, PHP 7.2.12, and the PHP 7.3.0-RC6 test release. All of the PHP5/PHP7 builds were configured and built in the same manner. All tests happened from the same Dell PowerEdge R7425 dual EPYC server running Ubuntu 18.10 Linux.
Besides continuing to evolve the performance of PHP7, the PHP 7.3 release is also delivering on FFI (the Foreign Function Interface) to access functions / variables / data structures from the C language, a platform-independent manner for obtaining information on network interfaces, an is_countable() call, WebP support within GD's image create from string, updated SQLite support, improved PHP garbage collection performance, and many other enhancements. PHP 7.3 is just shy of 10% faster than PHP 7.2 in the popular PHPBench. PHP 7.3 is 31% faster than PHP 7.0 or nearly 3x the speed of PHP5.
Besides continuing to evolve the performance of PHP7, the PHP 7.3 release is also delivering on FFI (the Foreign Function Interface) to access functions / variables / data structures from the C language, a platform-independent manner for obtaining information on network interfaces, an is_countable() call, WebP support within GD's image create from string, updated SQLite support, improved PHP garbage collection performance, and many other enhancements. PHP 7.3 is just shy of 10% faster than PHP 7.2 in the popular PHPBench. PHP 7.3 is 31% faster than PHP 7.0 or nearly 3x the speed of PHP5.
Re: No one in his right mind uses PHP these days (Score:2, Informative)
Python, Go, RoR 5, in that order
Re: No one in his right mind uses PHP these days (Score:1)
Python? Never used it for web backend, but wouldn't it make more sense to use something thats been developed for exactly that purpose for 25 years? i.e. PHP
Re: (Score:1)
PHP was designed for the 1993 era web. If you're still developing 1993-era web pages, stick with PHP.
If you have an html page and want to add some dynamic text, it's great. That's what it's optimized for. Rewriting something that's mostly static text with RoR or node or whatever is stupid.
OP asked about an API. Maybe something CRUD like (GET /anonymous_coward/posts to return a json array). Well, PHP can do it (possibly abusing 404 errors, possibly with apache/nginx URL rewriting. But it's going to b
Re: (Score:2)
Re: No one in his right mind uses PHP these days (Score:2)
As a programmer you need to be able to speak the most popular language of the web which is PHP. But, that doesnâ(TM)t mean you only need to use PHP. Just have an understanding of atleast 3 to 4 major languages and decide which one to use based the task you are trying to accomplish. Personally, I donâ(TM)t use Python for basic website with a backend. With both Flask and Django around I donâ(TM)t think python is a good programming language to use when it comes to web development . And on the ot
Re: (Score:2)
As a programmer you need to be able to speak the most popular language of the web which is PHP
No, you don't.
PHP in a good language (Score:5, Insightful)
Re: (Score:1, Interesting)
Who cares? It is convenient and flexible, it offers a lot of control and it works well.
Re: (Score:2)
Nobody's saying it can't be used.
The problem is the massive number of gotchas and little details you need to remember to be able to use it effectively. It's madness.
Re: PHP in a good language (Score:2)
Re: (Score:1)
Such as?
All the ways that ordinary comparison operators can do things you didn't expect.
The randomness of underlines in the function names.
etc.
Re: (Score:1)
All the ways that ordinary comparison operators can do things you didn't expect.
PHP's comparison operators aren't that complicated, really, and they are well documented. I have never had any actual problems with them.
The randomness of underlines in the function names.
There may be lots of theoretical arguments why the naming of functions in PHP is inconsistent and how that violates some principle, but it is not a problem when you are actually using PHP. It has no impact on usability whatsoever.
Re: (Score:2)
Once more, for the reading impaired: Nobody's saying it can't be used.
The claim is: It was "designed by clowns".
Re: (Score:3, Insightful)
That is one person's opinion from 7 years ago. PHP has advanced a bit since then.
Way to be dishonest though.
Re: (Score:3)
Which parts of that are no longer applicable?
Re: (Score:3)
Yep, no clear answers yet.
PHP 7 deprecated some more functions, broke a few things, added the spaceship operator, but apart from that it's basically the same. That page still applies.
http://php.net/manual/en/migra... [php.net]
Re: (Score:3)
I don't even know what you're trying to say.
Is the market share of something unspecified relevant to whether PHP 7 has fixed PHP or not?
Re: (Score:2)
A LOT of things mentioned on that page have changed. Which parts ? To name just 5 :
- PHP is naturally tied to Apache - no it isn't. There's PHP-FPM, there's Nginx Unit, it even works on IIS.
- php.ini applies to every PHP application run anywhere - there is a main php.ini but you can override this anywhere you want and in any webserver
- Similarly, there is no easy way to “insulate” a PHP application and its dependencies from the rest of a system. Running two applications that require different ve
Re: (Score:3)
A lot of those are things that are technically still in the language, but there are far better ways to do them now.
For instance, mysql_real_escape_string() was always a hack. The actual solution was proper placeholder syntax, which to be fair MySQL didn't support at the time even in its C API. We got that (in I think PHP5) with PDO, which is also database-agnostic.
The lack of type hinting in function return types was added (I think PHP7?).
Others are things that are clearly the result of the article author b
Re: (Score:3)
For instance, mysql_real_escape_string() was always a hack. The actual solution was proper placeholder syntax [...] We got that (in I think PHP5) with PDO, which is also database-agnostic.
Even PDO doesn't support passing an array as a parameter for, say, the right side of SQL operator IN. Sometimes it can be easier to make a loop that does $db->quote() and then always use that loop for IN than to generate a string of question marks of the appropriate length and ensure that the parameters before the list, the parameters in the list, and the parameters after the list are always bound in the same order.
The lack of parallel programming is because it's designed as a web server scripting language. You extract parallelism by having multiple requests from multiple users
Which doesn't help if you happen to have only one user, or a small number of users one at
Re: (Score:3)
Even PDO doesn't support passing an array as a parameter for, say, the right side of SQL operator IN. Sometimes it can be easier to make a loop that does $db->quote() and then always use that loop for IN than to generate a string of question marks of the appropriate length and ensure that the parameters before the list, the parameters in the list, and the parameters after the list are always bound in the same order.
Yeah, that is mildly annoying, but that's a pretty niche feature missing. I've wanted it maybe a half-dozen times in my career. (And I think it's a limitation of the underlying C APIs as well?)
Which doesn't help if you happen to have only one user, or a small number of users one at a time, doing relatively heavyweight queries. You might end up doing cURL on localhost to spawn a bunch of subprocesses.
If you *need* to spawn subprocesses, there is a module for it. It's not something 99% of users ever need to do, and is usually a sign that you're either using the wrong language entirely, or are architecting things completely ass-backwards.
Language design, as I said, is as much about choosing what features to leave ou
Re:PHP in a good language (Score:4, Interesting)
I tried to come up with a more balanced view on PHP, synthesizing Eevee's popular "fractal" essay, ManiacDan's "hardly" rebuttal, and Douglas Crockford's JavaScript: The Good Parts, to form coding standards and things that are still broken [pineight.com].
You have a point there. (Score:2)
Disclaimer: Professional PHP dev here.
One of the things really annoying about PHP is that it's so n00b friendly you run across tons of crap code. The upside is that PHP is quite hilarious. There's not a week that goes by that doesn't have me laugh out load about some quirky thing PHP had up its sleeve.
The truth is also that PHP is so domain specific that it really gets SSI programming done better than any other solution out there.
PHPs badness is its advantage.
Re:You have a point there. (Score:4, Informative)
The session-handling has been a strong point from the beginning, or so I've read. It's certainly easy to use. I'd rather write in Perl or another language, but for web stuff PHP has the win. Despite all the crazy functions, it's solid. Upgrading is easy, modules all fit. Still some fatal errors that should be warnings.
Re:PHP in a good language (Score:4, Insightful)
Re: (Score:1)
Re: (Score:2)
Well, you could argue: as literally everything except his PC and perhaps yours uses a kernel written in C ....
Re: (Score:3)
Virtually everything used to post your comment, from your local computer to the network to the server, was written in C++.
The browser, perhaps. Perl, httpd, the Linux kernel, those are in C.
Re: PHP in a good language (Score:1)
Re: (Score:1)
These day "increased performance" just means the developers will care about optimization even less than before.
The apps will bloat to absorb any difference within a couple of months.
Re: (Score:2)
To the contrary: Since the advent of time, increasing speed of a base process made other non-speed-optimized processes based on it feasible, leaving room for other developments.
Re: (Score:1)
But has it been rewritten to use the new and improved PHP?
Re: (Score:1)
Re: Why the constant focus on "performance"? (Score:4, Informative)
Re: Why the constant focus on "performance"? (Score:5, Interesting)
While this all makes sense, my problem with PHP ain't CPU burn, it's memory usage. What I need from my PHP CMS is for it to use less RAM, not for it to use less CPU. CPU is cheap, RAM ain't.
Re: (Score:2)
Memory is only used during a request. When a request is done, you get your free memory back. When a request is dealt with faster, you get more free memory in total (or you can handle more requests).
Re: (Score:2)
So what? I'm not waiting on PHP, ever. I'm waiting on the network or the database, and making PHP faster won't appreciably affect execution time.
Re: (Score:2)
So what? So wat? :)
Are you from Murica?
I thought Dutch people were rude, but muricans on slashdot are quite something too.
Re: Why the constant focus on "performance"? (Score:3)
I'm sure Facebook, arguably the largest PHP user on the web, would disagree with not needing more performance. An extra 1-2% performance bump is equivalent to getting an extra year of use out of compute resources they already own and have received a tax benefit from depreciation. It's million of dollars of free money.
Re: (Score:2)
My guess is Facebook uses HHVM, but a quick look around on the web didn't tell me how that related to normal PHP.
Re: (Score:1)
Facebook uses Hack. Originally, Hack was a PHP superset with types and some other extensions and better performance. In theory, PHP code could run under the Hack/HHVM interpreter/runtime without modifications. Around the time of PHP 7, Hack went their own way and is no longer a superset of PHP.
Prior to Hack/HHVM, they also tried HipHop, which transpiled PHP to C which was then compiled.
Re: (Score:2)
Isn't Facebook using HHVM ?