Hacker News new | past | comments | ask | show | jobs | submit login
How come PHP seems so much faster than Rust? (reddit.com)
108 points by fortran77 18 days ago | hide | past | web | favorite | 112 comments

While this discussion boils down to the efficiency of the underlying regex engines for PHP and Rust, it does highlight (to me) why PHP is so popular: in the hands of average programmers, PHP is quick to write and fast (enough) to execute.

I personally believe it's ubiquity is well-deserved, and I actually like it as a language despite all its quirks (which exist in almost every language I've come across)!

PHP isn't popular because it's easy, it's popular because for a long while it was the only viable language for developing web applications.

Indeed. I think most developers don't understand how amazing PHP was compared to the competition and just how fast it acquired new features during those early years.

It was a scripting engine with a such a thin layer of C that it could easily and quickly incorporate the huge number of open source C libraries that existed at the time.

While your observation is true to some degree, I do remember ASP, Cold fusion, CGI and a few other more obscure technologies way back when.

Perhaps I was quite late to the party though - I only started programming in 1999 (got a computer for my 11th birthday!) - so I'm not sure what it was like before then.

ASP and ColdFusion both required license fees at the time I believe (asp the Windows server license and CF of course the CF license)

CGI just would run any type of script. Originally that was typically Perl but PHP surpassed Perl for a variety of reasons. PHP could be run either through CGI or through mod_php in Apache. There was also a mod_perl I believe and a few others but php is what web hosts typically installed in the early 2000s.

Why did php beat perl?

Someone with better knowledge might step in here.

From https://perl.apache.org/about/history.html

> "PHP was also around already, and was an embarrassing witness to Perl's greatest weakness for server-side programming: that embedding Perl was a pain. Although the hooks were there for embedding Perl, they were both undocumented and buggy.

My other take on it is that PHP is like TypeScript, in that the path to adopting PHP from HTML is simple enough—just rename your HTML files with a .php suffix and you can add dynamic elements—or not. Just like how you can rename your JavaScript code with a .ts suffix and add types—or not.

Personally, I remember writing a few Perl CGI scripts. But I ended up using PHP for any quick-and-dirty dynamic stuff.

The web. Making a typical language output HTML required a lot of hoop-jumping or inventing a web framework in a time before Django and Rails. PHP was its own web framework.

Personally, I switched from Perl to PHP around 2002 (I could be wrong with the year) as I wanted to move from flat file dbs to MySQL. I wouldn't say that it beat Perl, it was just made web development more accessible. I still wrote in Perl after that, but for server side scripting (processing, cleanup etc).

Perl was just as inscrutable then as it is now.

Easy to write and easy to deploy. But that was a double edged sword.

> I do remember ASP, Cold fusion, CGI

This is the competition that PHP was so much better than.

I had a job 5 or 6 years ago where I needed to maintain/add to a website using ColdFusion. I actually kind of liked it, compared to PHP. That said I wasn't doing anything especially complex, which might have changed my mind.

CGI yes, ASP certainly not.

ASP was inaccessible for younger developers, tinkering with a linux box after school.

That is a very regional example.

Getting access to a Windows box was never a problem in countries with more flexibility towards piracy.

80 and 90's Portuguese students could get whatever they wanted from shaddy shops that used to copy books and software.

Booklets with 200+ items on them.

ASP required a license. That alone made PHP superior for many people.

Cheaper definitely, superior not.

Why are the two separate? Of course you include cost when evaluating with option is superior.

Because to be superior, the tooling and libraries also have to be superior.

PHP was only free beer with a clunky language and 3rd class DB support.

MySQL couldn't hold a candle to real RDMS back then, versus what was available with ODBC connectors.

> Because to be superior, the tooling and libraries also have to be superior.

Perhaps that is your definition, but the dictionary disagrees.

Your dictionary definition I guess.


I don't see definitions about being cheaper as sign of quality, quite the opposite.

Maybe you would like to share your dictionary as well?

Classic ASP was terrible; if you're thinking ASP.NET then that did not exist at the time.

Using OCX from ASP, written in Delphi, VB and C++ Builder, alongside VB Script, was definitely better than PHP 3.

Shared hosts didn't let you use anything but VBScript and JScript. Using COM components was a non-starter for the majority of users -- which is entirely the point.

The ones that offered IIS instead of ASP via Apache surely did, depending on the price plan.

There is no ASP via Apache. ASP was only ever hosted on IIS and given the huge security implications of running custom binaries on IIS in a shared environment, it almost wasn't ever done.

I started doing ASP development before my web host suggested it was cheaper and easier to do PHP. They had both Linux and Windows shared hosting at the time.

Sure there was one


I was only wrong regarding the language, it made use of Perl instead.

One esoteric library that was not mainstream. It's completely unrelated (and utterly incompatible) to Microsoft's ASP. I'm not even sure why you'd bother to bring it up -- what point does this make?

That PHP only got where it is today because of cheap hosting, down to the level of free beer, nothing more.

That doesn't explain how it beat a number of other technologies at the time -- including well established ones, like Perl.

Sure it does, cheap hosting. Many ISP only offered Perl with mod_perl, or telnet/cgi access, in the more expensive variants.

The cheapest of them all was PHP with files being dumped via FTP upload.

> I think most developers don't understand how amazing PHP was compared to the competition and just how fast it acquired new features during those early years.

The only competition in those early years was Perl iirc.

I'm not entirely sure if PHP was fast at acquiring new features.

PHP didn't have classes until version 4 iirc. Namespace in 5.4? And 5.x is around NodeJS early days where RoR and Python Django/Pylon/Pyramid was around.

I think how easy it is to pick up the language to do things contributed to its success. The template is built-in and 1000 functions in the global namespace.

> I'm not entirely sure if PHP was fast at acquiring new features.

You really have turn back the clock; languages didn't have package management back then. They didn't have packages. The only exception, at the time, was Perl (which had CPAN). PHP acquiring features was not just about language features but also how quickly it's standard library grew to accomplish anything you needed on the web.

> PHP didn't have classes until version 4 iirc. Namespace in 5.4? And 5.x is around NodeJS early days where RoR and Python Django/Pylon/Pyramid was around.

I'm actually talking about the PHP3 era; by the time we're talking about PHP5 then there was already plenty of competition and the "early days" were already long over.

Proper classes in 5.0, "true" OOP in 5.2.

Namespaces in 5.3

Javascript namespace/module handling is a nightmare, they should have copied PHP's.

Not sure I agree with this. Here's why: new tech stacks crop up every few months, and they're all competing for the same developer brain space. If PHP wasn't easy, I'm certain the interest in it would have evaporated to a large extent. Yet even today, people are choosing to start their projects in PHP. I think it's simplicity has a lot to do with it.

But PHP was essentially the original widely adopted lambda cloud function. 1,000s of dirt cheap shared hosting platforms showed up on the scene. The reason they could make the hosting so cheap was that the way PHP runs. You are only consuming resources when you are serving the request.

To this day, cloud functions still deal with "cold starts", where this was already a solved problem with PHP shared hosting.

All PHP needed to be was good enough. It was how it served pages that made it as popular as it was.

Large disclaimer, I know a PHP shared host was not actually scalable like AWS Lambda. Just the idea that any small business could plop down a few servers and start selling shared PHP hosting was huge back then.

It's more like, would someone else be able to maintain the code I write with language X? And would the person trying to run it be able to run in their environment without fiddling with SSH access?

If it's just me writing and deploying I use TypeScript but otherwise I tend to use PHP.

>for a long while [PHP] was the only viable language for developing web applications.

That is not what I remember. CGI existed before PHP (1994), and was used extensively for web apps (ebay still appears to use it to this day). Also, mod_perl and Java Servlets were introduced around the same time, circa 1996, so I don't think it's correct to say PHP had a monopoly on web apps "for a long while".

Not a monopoly, but it was the easiest and most performant option at lower price points.

Java required specialised or dedicated hosting ($$$). CGI was slow as hell. Mod_perl often was not available in shared hosting, for whatever reason.

PHP was cheap, fast, ubiquitous, and Good Enough™, for about a decade. Then VPS happened and the market changed.

Most people initially deployed php via CGI in my experience. I don't remember when mod_php arrived, but we'd been using PHP for quite some time at that point.

While CGI was slow-ish, alternatives like fastcgi were already around (and in fact running PHP via fastcgi was also quite common for a while.

By the time PHP became ubiquitous, most people had moved away from plain CGI regardless of language.

> in fact running PHP via fastcgi was also quite common for a while.

Mind clarifying how this is different from the current hotness (from what I can tell, due to a decade-old shortcoming that no longer exists in mod_php/Apache MPM options) where folks are running PHP via the Fastcgi Process Manager?

I don't think it is very different, other than hopefully maturity of the implementation. I've not had to set up any new PHP stuff for about a decade so I haven't kept up with what the current setups look like.

Re-reading it it sounds like it swung from fastcgi because Apache didn't have PHP support, to mod_php, and back to fastcgi (FPM) because Apache had poor concurrency support. It no longer does, but from someone who has to deal with this at their day job I can tell you that the current PHP ops wisdom is still stuck on not using mod_php.

The friction involved in getting those other technologies up and running was not trivial though. That played a role in php's initial success, because it was trivial to get up and running.

>The friction involved in getting those other technologies up and running was not trivial though.

That is only in relative terms in its time. For the past few years I keep thinking how the hell did Web Development went from Perl and CGI, arguably troublesome but understandable, to PHP which is ugly but easy to set up and running, to present days of... depending on which timeline you are, vagrant, VM, docker, k8s, Node.js... I would argue even Heroku with Ruby Rails isn't anywhere as easy as they were than the old days.

Indeed. I am much happier developing with Ruby on Rails than I was with say, PHP, but I do find it hilarious how back in the day deployment just meant uploading a couple of PHP files to a server and how now I need a full CI pipeline.

How so? As someone that's set them all up - with Apache the setup for mod_perl, php, and cgi are like the same right - they are all essentially cgi.

No, they are not the same as CGI. You can run PHP as a CGI, as many cheap hosts do, but for performance PHP is run as either Apache mod_php or php-fpm with Nginx. Mod_perl is not CGI and requires much more discipline to prevent shared memory leaks. Mod_perl allows content negotiation which CGI does not.

I remember it as a worse Perl, but with a bunch more web-batteries included. It's the latter that got me interested, way back in the day. Deployment story wasn't that different, aside from that cheap hosts were more likely to let you run PHP than Perl.

Coldfusion was also a thing around that time. Flash sites as well.

Yes, Flash was huge. When I was learning Perl around 2000 I shared a flat with a Flash animator who worked for an agency with huge clients such as Sky. It was all done in Flash for very big dollars.

Specifically to that point, Rasmus talks here about the reason PHP succeeded where Perl failed https://youtu.be/wCZ5TJCBWMg?t=552

I think rasmus's presentation explained pretty clearly why PHP won. Mod_php was a game changer and mod_perl failed by making the wrong choices. Overall, PHP was faster, easier, cutting edge and full of features without becoming too expensive to run, thats why web hosts supported it, not the other way around. What's not to love, honestly, even today.


Delphi, C++, VB have been viable since 1995, Smalltalk since 1995, Objective-C since 1996, Python since 1998, Java has been viable since 2001, C# and VB.NET since 2002.

PHP only became viable with version 3, around 1998, and having most ISP only offering a choice between CGI (usually C or Perl) and PHP, naturally drove most cost oriented devs to PHPs.

Those willing to shell out more, could use one of the above options.

Two other big factors in PHP's popularity in the early 2000s were its inclusion in Dreamweaver as an option for building dynamic sites and the profusion of "Build X with PHP & MySQL" magazine articles.

for how long? Perl existed when php started, as well as all the proprietary languages, java , asp etc. then came ruby python etc. It's not for the lack of competition


The same is true for python. I spent some time trying to write a CSV parser in guile scheme that was as fast as python's (mistakenly believing that python's CSV parser was actually written in python). I wrote a fast-ish streaming FSM-parser (about 100loc) but only managed to be about 1.7x as fast as python's CSV module. Browsing the python source I realised that the python parser was written in optimised and nicely buffered C.

I could probably compete with python if I used guile's lower level C-procedures, but I sort of lost interest after that :)

I don't like it from the security perspective, looking at just how many vulnerabilities PHP-based software has had, it's too trivial to create a XSS, SQLi, CSRF, LFI, RCE and many other classes of vulnerabilities. I think there are better options out there than on average give better results. Maybe it's just incredible selection bias I'm encountering \shrug.

Your argument is a form of survivorship bias. You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. People were writing sloppy PHP before CSRF and XSS were even invented. Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written.

You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation where programmers can't move fast enough in adding it to their stack. Data exfiltration is no longer a flaw but a feature.

> People were writing sloppy PHP before CSRF and XSS were even invented.

It is very very easy to write sloppy PHP, definitely easier than in many other languages and default frameworks.

> You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. P

I'm very aware of them, basically none have (had) as many high-impact vulns as PHP-based stuff does.

> Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written.

You're not acknowledging the orders of magnitudes difference between the impact of an usual PHP vuln and those you listed.

> You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation

The flaws in others are a very poor excuse for flaws in a thing itself.

But plenty of those vulnerabilities are not the fault of the language but the frameworks written by others. You can just as easily create SQL injection attacks in a Rust program or Ruby program. You can just as easily introduce XSS/CSRF problems in any of them. Etc.

If the majority of frameworks for a language are vunerable it's the language's fault. Python definitely doesn't have that issue, Rust and Go don't either.

> majority of frameworks for a language are vunerable

Where's your proof? Modern PHP frameworks are secure by default.

We're talking about the majority of frameworks that are being used, not about some newer versions 0.1% use. In the end arguing won't get neither of us anywhere, I get my livelihood from testing vulnerable software and you can keep writing software in PHP.

Majority of frameworks in use are:

Symfony Laravel CodeIgniter CakePHP Yii Zend Slim

All of these can (and recommend) using either PDO with named parameters, or a full ORM for SQL work. Most came packaged with a PDO (Doctrine, mostly) by default but have always supported whatever you wanted to use.

Write shit code, win shit prizes.

> You can just a easily create SQL injection attacks in a Rust program

I disagree, mostly on the grounds that string concatenation isn't very convenient, so it tends to be easier to do things "the right way" instead of hacking things together. Yes, you can do string concatenation using something like `format!(...)`, but at that point it's really similar to the correct solution that it's not really what you'd reach for by default.

And yeah, the community here is a huge part of it, and IMO languages can and should be judged by their communities. If a language's community promotes insecure solutions, that's a language that I don't want to use at my company because I don't want my employees following that example.

It’s really easy to write PHP, which means that people who don’t know about escaping input write PHP.

While there are some web-focussed languages (vs frameworks) that deliberately make it hard for you to write that sort of code, barely anyone uses them.

> It’s really easy to write PHP, which means that people who don’t know about escaping input write PHP.

Not trying call you out on this point, more it made me laugh. Our lead developer strips out characters that break his XML importer (lets just say they are standard common characters, heck, he changes chr(13) to a string so he can switch it back later because he doesn't know how to handle multiple lines in an XML value). People who don't know how to escape inputs / actually handle data properly are in every language. We cringe on a daily basis.

"escaping input" is a notorious delusion. And a bad one.

- it is not "input" must be treated, but, so to say - output. It's the destination that matters, not the source. By the time you get the input, you have no idea how and where it will be used. You can tell it right before the output (or, rather, better to call it "use") only. Say, you've got some input that didn't pass the verification and you will have to display it back in the HTML form. And if you already "escaped" it for SQL, it will be malformed. And vice-versa. Moreover, any data must be formatted properly before use, not just something that you tagged as "input".

- the word treated above is for a reason. Because the term "escaping" suggests some certain routine in PHP, which is the actual reason for numerous SQL injections.

You're right, my wording was inexact - we must always escape strings that can be controlled in some fashion by the user.

I'm working on comprehensive taint analysis for PHP[0], and I'm spending a bunch of time thinking about how to automatically detect those dirty strings.

[0] https://psalm.dev/articles/psalm-3-and-a-half#taint-analysis

This is a little silly. The two programs are so simple that it's probably just testing the speed of the regex engines used by the two languages. Since PHP uses PCRE (a C library that has been around for quite a long time), you'd expect it to be fast. I'm impressed that marshaling back and forth across the FFI boundary isn't causing more slowness, but perhaps it is, and the real issue is that rust's regex engine is just painfully slow.

The only way to know for sure would be to profile each bit to see what dominates: the file I/O? The regex matching? The FFI? The printing to stdout?

Also, looks like there is a rust wrapper for PCRE[0]; might be interesting to try it to get a more apples-to-apples comparison.

[0] https://github.com/cadencemarseille/rust-pcre

> This is a little silly.

Is it though? I interpreted question the following way.

"Rust is a tool in my tool box, when the reason for picking it over other tools isn't demonstrably true, what am i doing wrong?"

I agree with the rest of your comment, just not with calling the OP or their question silly.

You're right, and in hindsight I regret my tone there.

The reason for picking it is for memory safety as well as performance. If your problem involves a lot of regex and memory safety isn't as critical, then feel free to pick a language with good regular expression libraries. If regular expressions are a smaller part of your problem you're solving, looking at overall performance is better than benchmarks like this.

I'd never know that if this post didn't exist, so I don't think the investigation is silly at all.

Your conclusion is correct, but the reason I take issue is that that’s not the thesis of OP. OP’s original subject/headline suggests that, or questions why, Rust is generally slow vs PHP, and uses a regex example as the “proof”. A person who didn’t read the Reddit comments, or who is less versed in critical thinking, may accept the example as a valid proof of the thesis, instead of simply noting the fact that Rust may not be as good at regex as it is at other things. If the Reddit subject was “Rust is worse than PHP at regex”, nobody would bat an eyelid and the resulting conversational threads would have a different tenor (and your conclusion would and should be the same).

> and the real issue is that rust's regex engine is just painfully slow.

The benchmarks game suggests that it's quite fast: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

This is more than a little silly, and simply shows that the self-proclaimed PHP developer (who is "not surprised that PHP is 'fast'") has little to no idea what is costly in execution time, even in such a tiny example of a program, and has no idea how to figure that out.

What's silly is that somebody asked a legitimate question in good faith with code samples and everything, and you responded with an ad-hominem attack with no useful information.

Didn't someone here say we should judge a language by its community? Well the Rust community is not very nice.

OP of the Reddit post here. I made a Hacker News account just to come here and reply to you, because I would like to set the record straight in this regard.

I have always consistently found the Rust community to be nothing but amazingly helpful and friendly. I've posted in the Rust subreddit before in a different account and got the same helpful and friendly responses I did this time.

If we should judge a language by its community, then I, for one, wholeheartedly recommend Rust.

There was actually another post recently where someone asked a similar question only about Kotlin, and there ended up being this collaborative effort where people kept rewriting and optimizing both his Kotlin and his Rust code. Check it out:


There's an update too:


As one that has never, ever written a single program in Rust, am I part of a "Rust community"?

But I agree, I'm not nice at all, indeed.

On the contrary. I provided the most useful information there is (_T_I_N_Y_), even if I didn't hold your hand, either (although I wasn't really answering anyone's question, but rather commenting on it).

But we can't all be geniuses. I'm not one, either, but I don't feel attacked by anyone for pointing that out, and you shouldn't, either.

The top reply says "Don't underestimate PHP when regexes are involved." and linked a benchmark [1].

But in that benchmark apparently Rust is faster than PHP (The slowest "Rust #2" is 2.45 sec. while PHP is 2.80 sec. He also mentioned "PCRE", but the ones with Perl in name are even much more slower [the fastest being 14.95 sec.]).

Did I miss his point by linking that benchmark, or did I interpret the benchmark wrong?

[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

One could expect PHP to be a lot slower, the benchmark shows it can keep up. PCRE is the name of the regex library used by (among others) PHP, which is why PHP is good at regex.

Other comments address why the Rust program is not optimal.

I guess the poster didnt saw Rust being faster, only that PHP is pretty fast, or at least not slow (so it should be underestimated).

Id take that slowdown any day just not having to touch Rust though :^)

To be fair, the benchmarks game PHP script does quite more work that just matching a regexp, like forking into multiple interpreters (which can't be that fast) and communicating through a message queue.

So any speed difference between Rust's and PCRE/PHP gets lost among the noise.

Being within a factor of 2 of perfectly optimized C code is excellent performance for a program in any language, including C :) Note that the fastest Java and JS programs are 4x slower than this, and Python and Perl are even slower.

That said, I am surprised that Perl does so poorly. It might just be that no one's submitted a perfectly optimized solution for Perl?

> … "PCRE", but the ones with Perl in name…

fyi "Regular Expressions (Perl-Compatible)"


Thanks for letting me know.

look at the source code- all of the fastest are using PCRE

I believe the Rust Regex Unicode support is opt-out, where as in PHP it is opt-in. Might make a significant difference.

Cool. Never really noticed the non-Unicode variant would be faster. Here's some more info:


Random guess:

There will be some difference in the regex engine speed, because PCRE is very fast in common cases.

But doing a single regex match is not that much work, so it probably boils down to I/O.

And PHP might use extra buffering to get better throughput for the common "stream a file" scenario.

Similar question with Python being faster than C++:


> And PHP might

The program source code is shown.

Not the source code for PHP itself, though.

Obviously, because the PHP regex engine is written in C, not in PHP. It's more like Rust's regex crate vs C PCRE rather than PHP, or who calls system call faster. While Rust's IO is locked[1] and doesn't buffer (which is slower than buffered, unsynchronized IO like other languages). And regex crate is slow when capturing, which is used on the "benchmark".

Reference: https://www.reddit.com/r/rust/comments/5zit0e/regex_captures... 2 years ago, but it's still valid to me, I've just tested it and it's much slower as I expected. Feel free to correct me if I'm wrong :)

[1]: https://doc.rust-lang.org/std/io/fn.stdout.html

When you use any functions or classes any of the PHP standard library, the underlying implementation is usually in C.

I maybe wrong but rust uses a dfa regex engine, while pcre uses backtracking. So in theory rust's regex engine should be faster...

Seems like the flamegraph he took of his Rust program shows it using backtracking, maybe for the specific regexp he is using it's unable to use a DFA: https://i.imgur.com/9lx42Tu.png

This code is mostly just testing the regex engine?

Is the Rust regex engine slow because it's written in Rust?

Not really, it's mainly because it hasn't been optimized over many many years yet. Also, everything in Rust is implemented in Rust. Unlike interpreted languages like PHP, it's self-hosted.


Seems to be the case. All the same, given enough cases, I would expect that one can find something at which most major languages are faster by a generally faster language.


The php script and the log in question are probably in the kernel's aggressive block layer cache. The new files created by rust are potentially new and uncached, mean that it must be loaded from disk. Therefore the rust version is probably just losing time on disk access.

Quick test: review whether or not the rust version runs faster on the second execution.

Also or alternatively: use a profiler or copy the rust program to an in-memory block device (ramdisk) prior to access.

This is an interesting discussion. It seems that it's possible for i/o to be slow in Rust, and the PHP regex engine may be very good....

Rust doesn't make an average code implementation fast. Even naive mistakes like buffering / allocation make things really slow.

In regard to all bad criticisms PHP receives, I believe the language and ecosystem influence the way developers think. A bad language/ecosystem can dictate bad practices and bad design choices because that’s what the language encourages them to do. I remember every PHP-4/5 training course starting by mixing PHP and HTML.

Majority of developers write crappy code even on a decent environment. But there is so much old and bad PHP code out there as a result of many years of teaching how to right bad PHP code that nothing can stop these bad criticisms forever.

I don't write PHP at this moment but I know PHP7 made major improvements. PHP is still a very good choice for rapid web development and fits for many startups, small, and medium size business, and there are many successful examples to back it up.

Regarding the slowness of Go in the benchmarks linked in the article, https://medium.com/@dgryski/speeding-up-regexp-matching-with....

There are tradeoffs with PCRE vs RE2 instead of just raw speed.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact