[smt88]

> I was under the impression that PHP's stateless nature, with a whole new instance of everything coming into being for each request

A couple issues here.

1. Even if the PHP process exits after each request, memory leaks during the request are still an issue. If I'm looping through 1,000 elements of an array and leaking memory each time, I could end up with a peak memory usage of 100MB when 1MB would've sufficed. That forces me to scale vertically when I might not otherwise need to.

2. Most mature applications have worker processes that may be longer-lived than serving an HTTP request. If PHP leaks memory, it's less suited to those tasks. Maybe you write those in Go instead, but then you have to ask yourself why you didn't just write the whole application in Go.

[CaveTech]

1. This is likely user error due to a poor understanding of how PHP memory management works. Unless you're using poorly written extensions then memory management in PHP is quite straightforward.

2. There's a large amount of PHP libraries built to do exactly what you're describing. Long lived PHP processes are live in production across the world.

Straight up misinformation.

[smt88]

Note: I wrote PHP professionally for more than 10 years, and I still maintain several PHP code bases.

> This is likely user error due to a poor understanding of how PHP memory management works.

This is not what the comment I responding to was talking about. They were talking about memory leaks that were not in userspace. PHP's bug tracker has 943 bugs related to memory leaks[1]. That has nothing to do with understanding "how PHP memory management works".

> Unless you're using poorly written extensions then memory management in PHP is quite straightforward.

How exactly do you know whether an extension is poorly written? In many cases, it doesn't matter because there's exactly one extension that does what you need.

You could also be using poorly-written libraries.

> There's a large amount of PHP libraries built to do exactly what you're describing. Long lived PHP processes are live in production across the world.

I know. I use some, and I have several long-lived PHP processes running right now.

If a memory leak is in PHP itself, no library can fix it.

> Straight up misinformation.

Disagreeing with someone (or not understanding them) doesn't mean they're spreading misinformation.

My point was that memory leaks in the PHP virtual machine are still a problem even if PHP usually runs statelessly. Do you disagree?

1. https://bugs.php.net/search.php?search_for=leak&boolean=0&li...

[muglug]

Ok, but looking at that same bug tracker there are only a handful of memory leaks in PHP core (i.e. not related to an extension), the most serious of which is being actively worked on: https://bugs.php.net/bug.php?id=76982