Skip to content

Per-message PHP allocation churn is real but negligible: do not spend effort here (measured) #310

Description

@s2x

Impact Low · Confidence measured · Hot path yes

Location Sender::send() (two nested closures + array_merge + 3 Envelope->last() per send), Receiver::get() (one closure per queue per call), Receiver::ack()/reject() (one closure per call + withRetry wrapper), ConnectionRetry::withRetry (~52 ns overhead over a direct call).

Cost today Measured on this machine: closure alloc 58 ns, array_merge 55 ns, withRetry wrapper +52 ns, Envelope->last 26 ns. Total pure-PHP transport overhead per message ≈ 0.3–0.6 µs — under 0.1% of one 1 ms broker RTT.

Why it is (barely) avoidable The get() callback and the ack/reject operation closures could be hoisted to properties bound once per connect; getRoutingKeyForMessage/flag resolution could early-exit. Worth doing only as a by-product of P1/#306/P4/#309 refactors.

Evidence scratchpad/bench.php output in "Method and limits".

Suggested fix None standalone. Hoist the consume callback to a property when implementing P4/#309.

How to measure Not worth a dedicated benchmark; any effect is invisible next to one RTT.


Source: audit/performance.md § P5 — Fable audit, 2026-08-18, against HEAD 88db1e4. Findings marked verified were reproduced live against RabbitMQ 4.1 with ext-amqp 2.2.0; see the Confidence line above for anything weaker.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    performancePerformance / throughput / latencyphpPull requests that update php codepriority:trivialTrivial priority

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions