Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

611–620 of 673 posts

Re: Taking PHP Seriously

#611

Post by [deleted] »

Shorel wrote: post #589
kuschku wrote: post #19

Earlier quoted context omitted.

> So what's the catch? About 2-3 orders of magnitude in performance. That’s the catch. And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc. And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framewor…

I don't know where do you get your 2-3 orders of magnitude from. A rewrite I worked on, from PHP to C++, had an improvement of 20 times better performance. That's only one (1) order of magnitude.

[deleted]

Re: Taking PHP Seriously

#612

Post by kuschku »

Shorel wrote: post #589
kuschku wrote: post #19

Earlier quoted context omitted.

> So what's the catch? About 2-3 orders of magnitude in performance. That’s the catch. And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc. And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framewor…

I don't know where do you get your 2-3 orders of magnitude from. A rewrite I worked on, from PHP to C++, had an improvement of 20 times better performance. That's only one (1) order of magnitude.

From benchmarks such as http://www.techempower.com/benchmarks/#section=data-r11&hw=p... ?

Compare Symfony2 with Spring, for example (~500 vs. ~22'000 responses per second).

Or if you want to only use the raw language itself, php-raw with ulib-postgres (~90'000 vs. ~300'000 responses per second)

And with PHP, the larger the codebase, the slower it always responds, because even with opcaches loading it into RAM is a major bottleneck.

That’s exactly the issue at hand here.

And compare actual performance, for example JSON serialization, that’s not even fair anymore, symfony2 reaches around ~2'000 a second, gemini, the fastest fullstack framework, reaches ~970'000 a second.

Raw PHP reaches still ~170'000, but the fastest non-PHP raw language is still at ~2'200'000 compared to that.

These are actual performance issues that will cost you actual money. Even saving 20% of hardware and server costs can be the difference between your company being cost-effective and dead.

Re: Taking PHP Seriously

#613

Post by [deleted] »

Shorel wrote: post #589
kuschku wrote: post #19

Earlier quoted context omitted.

> So what's the catch? About 2-3 orders of magnitude in performance. That’s the catch. And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc. And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framewor…

I don't know where do you get your 2-3 orders of magnitude from. A rewrite I worked on, from PHP to C++, had an improvement of 20 times better performance. That's only one (1) order of magnitude.

[deleted]

Re: Taking PHP Seriously

#614

Post by cagataygurturk »

dpcx wrote: post #255
toast0 wrote: post #157

Earlier quoted context omitted.

> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing…

IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. That's the job of the autoloader. And if I'm writing my code remotely well enough, each section only uses the things that it needs. Granted, there may be some things that each request get that they don't need with the autoloader. But I can optimize later. "Make it work, make it right, make it fast"

> IMHO, developer time is more expensive than CPU time

I see that you've never worked on a project where the CPU time needed to handle the traffic with crappy code is much more expensive than developer time to write efficient software.

Re: Taking PHP Seriously

#615

Post by floatboth »

oridecon wrote: post #569
BaconJuice wrote: post #521

Earlier quoted context omitted.

Hi, can you list all the worst practices you see in this code? Just curious of the full list

I'm no expert but since he didn't reply: - Use of mysql_ functions (This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be used) - Using the user input directly in the query instead of binding, using prepared statements, or at the very least casting to an integer (don't do this) - (besides mixing multiple layers) Possible whitespace problems i…

> The closing ?> tag MUST be omitted from files containing only PHP.

It doesn't contain only PHP. There's the closing JSON } after ?> :D

Re: Taking PHP Seriously

#616

Post by ufmace »

Shanea93 wrote: post #605
tigershark wrote: post #585

Earlier quoted context omitted.

I don't care about performance. Unless we are speaking about orders of magnitude and my use case has an absolute need for performance. If I only cared about performance I would write everything in assembly optimised for every specific architecture. But strangely I'm much, much, much more productive writing in c#, Java, groovy, f#, ruby and whatever language is appropriate for what I need to do at a certain time. For…

Most professional PHP developers I've anecdotally worked with use a Model-View-Controller pattern these days, where the SQL is abstracted away in the model under something like Doctrine2-DBAL, Propel2 or PDO. If I was hiring for a developer and they suggested putting raw SQL in the view layer, I would reject them. If I received a pull request from my team which did the same, I would reject it. You seem unnecessarily…

This exactly. Never been a PHP developer, but I did get handed a PHP webapp to copy some functionality out of for a replacement C# webapp. I was a little surprised to find out that it was written in a rather Rails-like architecture using some PHP MVC library, I think it was CakePHP. Rails was a hit, and a great step forward in web development, so naturally every other language copied as much of it as possible, including PHP. There may be plenty of weird quirks about the language still, but at least the architecture is much improved.

Re: Taking PHP Seriously

#617

Post by Klathmon »

gkya wrote: post #609
Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

It's interesting that so little know what is Cgi here. It's the Common Gateway Interface and it uses environment variables to communicate to the Cgi scripts and thus the Cgi script can be in whatever language you wish. You don't even need a lib, reading env is enough. Its possible to write your Cgi scripts in assembly. So this process-per-request thing is not exclusively a Php thing.

I know of CGI scripts (and the newer faster alternatives), I was wondering why more languages don't specifically target that kind of setup, playing to its benefits and trying to minimize the downsides.

Re: Taking PHP Seriously

#618

Post by yahyaheee »

dokeke2 wrote: post #602
yahyaheee wrote: post #313

This is nonsense. As someone who has had to work in PHP environments that were a mess, just write Python or Go they are worlds better

as someone who has been in the industry for over a decade: when i hear people say stuff like this, I assume they are a rookie dev. Have passed on many interview candidates for it.

As someone who has been in the industry for 6 years, I'm certainly not a rookie dev. I have simply witnessed the horrors of PHP. I don't know who in their right mind would pick PHP over Python or Go. For high volume API work you simply can't beat Go nowadays. It's fast to write, stable as hell, and the TechEmpower benchmarks make it obvious how performant it is. Python has the added bonus of all the Data Science/ML libraries with it, which seems to be the way the world is turning nowadays. Not to mention that Flask with Meinheld workers also does very well performance wise.

To me you sound like a guy who has spent most of the last decade writing PHP. I've know a couple devs who used to defend PHP vigorously, mainly because thats what they knew best. Now they all write Go and haven't looked back. PHP is a story of right place right time, thats all there is too it.

Re: Taking PHP Seriously

#619

Post by gkya »

Klathmon wrote: post #617
gkya wrote: post #609

Earlier quoted context omitted.

It's interesting that so little know what is Cgi here. It's the Common Gateway Interface and it uses environment variables to communicate to the Cgi scripts and thus the Cgi script can be in whatever language you wish. You don't even need a lib, reading env is enough. Its possible to write your Cgi scripts in assembly. So this process-per-request thing is not exclusively a Php thing.

I know of CGI scripts (and the newer faster alternatives), I was wondering why more languages don't specifically target that kind of setup, playing to its benefits and trying to minimize the downsides.

Oh, sorry. I guess it's two-fold then: a) it's not as popular and cool, and then b) not much needs to be done to target it anyways, as most often being a good unix citizen suffices, you get the input and write the output to stdout, what's in between is application realm and whatever you do is up to you.

Re: Taking PHP Seriously

#620

Post by sigi45 »

Wrote Java code for few years and was writing php code the last 2,8 years.

While it doesn't matter that much at the end of the day, php is slow compared to java. A language which has so much hidden potential performance (from 5.6 to 7) can't be that good.

Also a lot of stuff i was used to in java is now also how php developer write code but with a language which doesn't support it properly. Annotations for example.

The worst thing was the type annotations in comments. Why do you write type annotations in your php comments? Because otherwise your ide can't protect you from those errors. and it doesn't provide you with proper code completion.

When you use tomcat and basic servlets or spring, you can write code quick and easy without any problems. Not sure why you wanna would use php.

Tooling is much better (IDE support, Profiler support) and Debugging is much better (simple to connect, can drop frames) and yes java has hot code replacement.

I can change the code while i'm debugging it and than drop the frame and test it again without reloading anything.

And at the end of the day you do know a language which you can use for android, server, games, desktop clients and it is cross platform out of the box.

Post reply on HN