[axelthegerman]

If that "bottleneck" is thousands of requests per second then it doesn't really matter for smaller deployments does it? (Which seems to be the target audience and not FAANG)

I'm not a big fan when folks call out languages as bottlenecks when they have no proof on the actual overhead and how much faster it would be in another language.

[that_guy_iain]

To tweak a PHP deployment to handle hundreds of requests per second which is very very realistic for a basic logging for a mid-sized application you're looking at having a very beefy server setup.

Most PHP deployments barely reach a hundred per server.

And this is an open source project is should be designed to handle basic production workloads which it could but it'll cost you a bunch more than if you used the correct languages.

> I'm not a big fan when folks call out languages as bottlenecks when they have no proof on the actual overhead and how much faster it would be in another language.

Honestly, I thought it was so obvious that an interpreted language is not good for high throughput endpoints that it didn't need to be proven. I also thought it was obvious that a logging system is going to handle lots and lots of data.

It could be easily proven by doing a bunch of work but obviously there is no point in me proving it.

[mrngm]

Well, looking at our bespoke logging system in PHP handling some 15-20+ million log entry's per day on a virtualized dual-core system... it's mostly disk I/O on the underlying MySQL database (currently duplicating to Clickhouse where we'll eventually store everything). And that is central application logging for about 100 servers (think syslog), some 400 "microservices" (parts of a larger application), and a handful of backend systems.

We're running out of disk space earlier than that PHP is a bottleneck here.

[Implicated]

> To tweak a PHP deployment to handle hundreds of requests per second which is very very realistic for a basic logging for a mid-sized application you're looking at having a very beefy server setup.

There's just no way that you're at all familiar with PHP of the last 10 years to think this is true.

> It could be easily proven by doing a bunch of work but obviously there is no point in me proving it.

Prove it. Please, show me the context and environment you think PHP would struggle to serve "hundreds of requests per second". I'd venture a bet that a plain Laravel installation on the cheapest digital ocean droplet would top this and Laravel is "slow" in relation to vanilla PHP.

[withinboredom]

I rebuilt durable-functions in php. Durable Functions is a C# actor model runtime. My PHP implementation meets or exceeds the same benchmarks as the C# version.

> It could be easily proven by doing a bunch of work but obviously there is no point in me proving it.

Because you cannot prove it... :) I wrote this post a few years ago, that actually spurned some improvements in C# ... so here you go: https://withinboredom.info/2022/03/16/yes-php-is-faster-than...

[that_guy_iain]

No, it's because I've got productive things to do that do benchmarks that have already been done repeatedly. The only way to get PHP to the same speed as compiled languages for web requests is to use experimental tooling.

I notice your benchmarks are over 10 runs?! That's not a good sample size. And even more importantly, it's not in the same context.

Sure once you compile PHP and have it running it'll run fast. But PHP has a very specific usage which is web applications. It's been well-known for years that PHP's performance issues are related to the fact it's an interpreted language that has to be interpreted everytime but if you compile and run repeatedly it can perform extremely well. Which is why every performance related PHP nerd is working on experimental tools to do that.

[withinboredom]

> That's not a good sample size.

Like I said in the blog post, if I tell you the sky is blue and you don't believe me; run them yourself. FWIW, C# is faster now for that particular use case. Also, like I mentioned in a previous blog post ... which one would you rather maintain:

- https://github.com/TheAlgorithms/C-Sharp/blob/master/Algorit... -- merge sort in C# 130 lines

- https://www.w3resource.com/php-exercises/searching-and-sorti... -- merge sort in PHP 60 lines

PHP is often far more concise than C#, and many other languages. I code more in Go than C# or PHP these days, but even Go has its limitations where it would be easier to express in PHP than Go. There are even certain classes of algorithms that are butt-ugly in Go but quite pretty in PHP.

PHP is still my favorite language, even though I hardly get to use it these days.

> PHP has a very specific usage which is web applications.

Originally, yes. But it outgrew that about 10 years or so ago. It's much more general purpose now.[1][2]

[1]: https://nativephp.com/ -- desktop applications in php

[2]: https://static-php.dev/ -- build self-contained, statically compiled clis written in php

[phillipcarter]

The C# to PHP comparison is not fair, as the link you gave for the C# code uses abstractions to support "arrays" that could also be backed by file storage. An equivalent translation of the PHP code is about 60 lines as well, before applying any code golfing (and including comments and whitespace).

[neonsunset]

You do realize that you are comparing two different implementations with different type systems that use different abstractions? Clearly you can't be serious. So, unless you are being intentionally misleading, this raises questions about the quality of "PHP solution" that is being worked on.

[withinboredom]

I'm being serious in using it as an example of maintainability/expressiveness. The difference is deliberate, not accidental. I've written 15 PHP lines that would be hundreds of lines in C#, and I've written 15 lines of Go that would be hundreds of lines of PHP. Every language has its own strengths and weaknesses and levels of complexity. PHP fits into a sweet spot (IMHO) of low-levelness and high-levelness, but it is often not seriously considered due to its reputation in the 00's.

[mrngm]

I'm sure you've heard of PHP's opcache by now. That's not experimental and actually caches the interpreted code in memory for faster subsequent execution.

[that_guy_iain]

Yes, it makes it faster but does not deal with the core performance issues which is why Roadrunner, Frankenphp, etc exist.

[Implicated]

I see, you're just trolling at this point.

[withinboredom]

Yes, and in 8.4, uses an actual IR for machine code generation and is pretty cool!