perf: reuse timers

[dunglas]

This patch significantly improves performance by allowing reusing timers instead of creating and deleting them at every request. With this patch, PHP does only 2 syscalls per thread (a thread can handle many requests sequentially) instead of 2 per request.

As PHP doesn't manage threads itself, calling zend_max_execution_timer_shutdown() when a thread is terminated will now be the responsibility of the caller. I think that this change is acceptable because threads are often used to handle requests until the process terminates (it's what FrankenPHP does for instance), so even if zend_max_execution_timer_shutdown() isn't called explicitly (which is better and should be done by SAPIs using threads), the OS will destroy the timers when after the process termination.

cc @arnaud-lb

[staabm]

Do you have numbers?

[dunglas]

I'll publish a benchmark used by FrankenPHP next week.

[arnaud-lb]

This looks reasonable to me. The change is low-risk as it only impacts --enable-zend-max-execution-timers, which is only used by FrankenPHP currently. Thus, targeting release branches is likely acceptable if benchmarks justify it.

Did you consider removing the zend_max_execution_timer_init() call from init_executor() as an alternative to the early return? (for non-ZTS build this would also require to call zend_max_execution_timer_init() once per process, maybe in zend_startup().)

[bukka]

We should not be introducing features to stable versions (no matter what the feature is). I'm preparing RFC that touches that topic (introducing features in stable and RC versions) so it would be good to delay this at least until this is decided. I will announce it in the next few days hopefully.

[bukka]

I think the main problem with this is that it creates somehow precedent for other things targeting stable versions. I'm aware that this is sometimes done but I don't think that's a good thing for stability.

[dunglas]

Closing as #13027 does exactly the same thing.