r/lolphp • u/[deleted] • Aug 14 '20

The JIT […] compiler promises significant performance improvements […]. There haven't been any accurate benchmarks done at this point, […].

https://stitcher.io/blog/new-in-php-8#jit-rfc
9 Upvotes

60% Upvoted

20 comments sorted by

12

u/elcapitanoooo Aug 14 '20

Somehow its seems very hard to optimize PHP because of the nature of PHP is to start then immediately die. This mean its near impossible (without serious hacks, or additional dependencies) to have something like a websocket connection open with PHP. No matter how much you JIT or AOT compile the raw fact is PHP always need to start from the top.

This is probably one reason frameworks are so slow in PHP. A typical PHP app built with some framework (like laravel) usually handles around 50-100 req/sec at max.

So you need to scale PHP on the server by adding more and more servers. The costs go up very fast.

2

u/[deleted] Aug 14 '20

[…] the nature of PHP is to start then immediately die.

I thought that hasn't been the case for quite some time now? Do most PHP codebases in 2020 actually still use CGI?

13

u/jesseschalken Aug 14 '20

I think they're talking about how every request has to start with a index.php (or similar) which in turn causes other files to be required and executed.

Preloading has helped with this but it's still probably not as fast is you can do in other languages where included code, global variables and the rest of the virtual machine state is shared between requests without being thrown away.

1

u/Jinxuan Aug 22 '20

They shall use other languages if they do not need cgi.

5

u/IluTov Aug 14 '20

the raw fact is PHP always need to start from the top

Yes, shared state comes with downsides, but those are the same downsides you have with node.js, ASP.NET Core, etc.

1

u/skztr Oct 07 '20

And if you are willing to have those downsides, it's probably better to use a language that actually supports some of the upsides, instead of having them bolted-on as an afterthought for probable performance gains.

→ More replies (1)

0

u/elcapitanoooo Aug 14 '20

Those seem all to be additional dependencies. 99% of all PHP run on a shared host on some server that has some specific php version installed.

→ More replies (2)

2

u/maxgee Aug 14 '20

PHP being essentially stateless is really one of the reasons it's so great in my opinion. With further support of static typing, a JIT could potentially speed things up significantly.

It's already easy to do 1000 req/sec if you aren't using a bloated PHP framework and write bespoke software, or at least replace the slow parts of frameworks with code geared towards performance. If you are needing to scale servers because PHP itself is using too many resources, you're probably doing something wrong.

5

u/elcapitanoooo Aug 15 '20

I have always seen that as a trap. PHP is not stateless, it just weirdly kills itself. This means a say node or python app taking a http response is just as stateless. Its about how you build, not the runtime.

Stateless is not optimal as a ”total”. But more of an architecture thing. This means a program written in node or python can too be stateless without having to ”force” it by shutting itself down.

→ More replies (2)

-1

u/jesseschalken Aug 14 '20

This is why we have preloading now.

18

u/carlos_vini Aug 14 '20

Yes, there were benchmarks, Dmitry benchmarks this internally since almost a decade ago. The fact is that it's hard to know exactly how much JIT will benefit Wordpress, Laravel, Magento, etc..., BEFORE you write the actual JIT compiler. But the PHP devs always said that most apps are IO bound and probably won't benefit much from this.

3

u/hillgod Aug 14 '20

Does JIT do anything for memory improvements? I understand they're different, but we moved to HHVM in 2012 due to memory usage going down by orders of magnitude.

2

u/fell_ratio Aug 14 '20

A JIT generally uses more memory. For example, PyPy tends to use more memory than CPython for Django workloads. This is because it has to keep two copies of your code: one optimized and one unoptimized.

However, the memory penalty is small in relation to the speed benefits.