Next steps for improving GC performance and configurability

[dktapps]

Problem description

Since the implementation of #6554, several server owners have been discovering that GC is the source of many of their mysterious performance woes.

This PR didn't worsen performance, but it did make the problem appear in an obvious place in timings reports, rather than in random code pathways.

I was aware when I made the PR that the parameters were probably not optimal for PM's use case, but my focus was on ensuring that the behaviour properly mirrored the PHP standard behaviour so that I didn't accidentally hurt performance. It appears I succeeded in that goal, and now it's time to do something about these issues.

Proposed solution

Several steps come to mind:

• Allow turning off the cycle GC entirely. PM by itself doesn't really need it (since it destroys all known cycles explicitly when objects are done with), and if plugin devs on servers are conscious of cycles, they may not need this expensive GC at all.
• Allow configuring GC parameters like the GC threshold step, GC starting buffer size, GC threshold increase trigger, etc.
• Allow setting a minimum time between GC runs. Larger servers have found that the GC runs far too frequently and wastes lots of CPU time trying to collect long-lived objects like Server and Player.
• Look at integrating something like ext-gcignore so we can stop the GC wasting time on expensive objects. This will significantly reduce the GC burden.

Alternative solutions or workarounds

No response

[GameParrot]

Would it be possible to make an extension that helps developers find the source of cycles

[dktapps]

Unfortunately the GC doesn't give us much outward stats information, so it's difficult to see what types of objects it's spending time on. I only experimentally verified that Server, Player and World objects were wasting a lot of time. Getting more out of it would require modifications to php-src because that information isn't exposed.