Make use of fast_shutdown to avoid freeing overhead#3429
Conversation
Signed-off-by: Bob Weinand <[email protected]>
Benchmarks [ tracer ]Benchmark execution time: 2025-09-22 19:06:03 Comparing candidate commit a3e585a in PR branch Found 5 performance improvements and 1 performance regressions! Performance is the same for 188 metrics, 0 unstable metrics. scenario:ComposerTelemetryBench/benchTelemetryParsing
scenario:MessagePackSerializationBench/benchMessagePackSerialization
scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache
scenario:TraceAnnotationsBench/benchTraceAnnotationOverhead-opcache
scenario:TraceFlushBench/benchFlushTrace
scenario:TraceSerializationBench/benchSerializeTrace
|
morrisonlevi
left a comment
morrisonlevi
left a comment
There was a problem hiding this comment.
I see fast shutdown is inversely related to full_tables_cleanup, but I'm not exactly sure when that is set. My guess based on scanning code is that full_tables_cleanup is mostly 0, so most of the time on this branch we would be doing fast shutdown?
As for the details, it looks like it skips calling destructors. Are you certain this is correct, even in weird conditions like fatals or unhandled exceptions, etc?
Also, it seems like the allocation profiler would interfere with this optimization, since it checks is_zend_mm, yeah?
|
@morrisonlevi I copy pasted the logic from shutdown_executor() in php-src, so it should be fine. And yes, full_tables_cleanup is generally 0. Also no, it doesn't skip calling destructors (zend_call_destructors happens directly in php_request_shutdown). It skips freeing the objects though. However, the allocation profiler is a problem, but that's slightly orthogonal - this makes the whole fast_shutdown of PHP not work. That's something the profiler should address though. |
3 participants
Note that mistakes in terms of fast_shutdown can lead to actual memory leaks!
We need to ensure stability on memory for this one.