refactor: encapsulate ALLOCATION_PROFILING_STATS for safety#3519
Conversation
Benchmarks [ profiler ]Benchmark execution time: 2025-12-06 00:35:51 Comparing candidate commit 22d474a in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 29 metrics, 7 unstable metrics. |
Benchmarks [ tracer ]Benchmark execution time: 2025-12-06 01:27:30 Comparing candidate commit 22d474a in PR branch Found 3 performance improvements and 5 performance regressions! Performance is the same for 185 metrics, 1 unstable metrics. scenario:ComposerTelemetryBench/benchTelemetryParsing-opcache
scenario:MessagePackSerializationBench/benchMessagePackSerialization
scenario:SamplingRuleMatchingBench/benchRegexMatching1
scenario:SamplingRuleMatchingBench/benchRegexMatching2
scenario:SamplingRuleMatchingBench/benchRegexMatching3
scenario:SamplingRuleMatchingBench/benchRegexMatching4
scenario:SpanBench/benchOpenTelemetryAPI
scenario:TraceSerializationBench/benchSerializeTrace
|
realFlowControl
left a comment
realFlowControl
left a comment
There was a problem hiding this comment.
I fixed a comment that ended mid-sentence. Otherwise, nice and clean 🚀
realFlowControl
merged commit 476c702
into
florian/stabilize-and-speedup-allocations
Co-authored-by: Florian Engelhardt <[email protected]>
2 participants
Description
Florian and I have been working to optimize the memory profiler in PR #3505, including writing some unsafe code. Rather than spreading the unsafe bits all over, I tried my hand at encapsulating them.
Now that
ALLOCATION_PROFILING_STATSis private, and all public APIs do not allow the caller to keep references to it, we can say thatallocation_profiling_stats_should_collectis safe. This does require thatginitandgshutdownwere called correctly in the correct PHP lifecycle hooks, so I documented those and marked them unsafe as well.Reviewer checklist