core: a call pays the remote path's cost whether or not it takes it — 19 allocations, two CompletionStates, two strings per dispatch

[Yaraslaut]

Consolidates #526 (F8), #527 (F9) and #529 (F11) from the #518 sweep. Those three are closed in favour of this one; each is reproduced here in full, with its own verification status preserved.

They are merged because they share a fix site and a single measurement. #527 says so itself: "Raise it together with F8; they share a fix site and should be measured together." #529 is the same budget on the server-side path.

The finding

A call through morph pays for the remote path whether or not it takes it. Three distinct mechanisms:

Part A — the marshalling apparatus is built unconditionally (was #526, measured)

Bridge::executeVia constructs serializeAction and deserializeResult on every call (bridge.hpp:1466-1469) including when the installed backend is LocalBackend and will never use them; the two type-ids are std::string copies of compile-time constants (bridge.hpp:1463-1464); the action is make_shared'd even when it is a 4-byte POD (:1465).

Measured. Revision: master @ 4017228d. Global operator new counter, g++ 15 -std=c++23 -O2 -DNDEBUG, struct Ping { int x; } -> struct Pong { int y; } through LocalBackend — no JSON, no socket, just an integer doubling. 50 warm-up calls excluded.

local execute round-trips  : 200
heap allocations total     : 3,837   (19.2 per call)
bytes allocated total      : 396,544 (1,983 per call)

caller-side execute()+then(): 12.8 allocations per call
throughput                 : 20,000 calls in 0.031s
                             654,528 calls/s  (1.5 us/call)

Attribution, by reading bridge.hpp:1462-1470 and backend.hpp:798-886: 2 strings (call.modelTypeId, call.actionTypeId); 3 std::functions, each capturing a shared_ptr — not trivially copyable, so libstdc++ cannot use its small-buffer path and heap-allocates; 1 make_shared<Action>; 2 make_shared<CompletionState> (Part B); plus the strand task's std::function, a possible make_shared<Strand>, map nodes, and the GUI-side dispatch closure.

Not verified: the per-source attribution is by reading, not by instrumenting each allocation site. The totals are measured.

Part B — two CompletionStates per call (was #527, inferred from reading the code)

The backend produces a Completion<std::shared_ptr<void>> (backend.hpp:801-802); executeVia attaches a forwarding .then/.onError pair that static_casts to R* and settles a second, typed state (bridge.hpp:1416-1417, :1571-1620). Every call allocates two mutexes, two handler vectors and two control blocks, and hops the callback executor twice.

Not reproduced. Revision: master @ 4017228d. The two make_shared<CompletionState> calls are part of Part A's measured 19.2 allocations, but their individual cost was not isolated.

Part C — two string allocations per server-side dispatch (was #529, inferred from reading the code)

ActionDispatcher::dispatch takes two string_views and materialises both into a std::string pair purely to perform a hash lookup (registry.hpp:560-568):

std::string dispatch(std::string_view modelId, std::string_view actionId, ...) {
    Key const key{std::string{modelId}, std::string{actionId}};   // 2 allocations
    auto iter = _runners.find(key);

The same pattern repeats in coalesce (:577), schemaFor (:596) and requiredFieldsFor (:664). ActionDispatcher also keeps four parallel maps on the same key (registry.hpp:687-690).

Not reproduced. Two std::string constructions from string_view allocate whenever the id exceeds the SSO buffer; morph's own ids ("EchoModel", "GetAccount") are typically within SSO, so the real cost may be lower than the worst case. It was not measured, and whether typical ladder ids exceed the 15-byte libstdc++ SSO threshold was not checked ("CreateSwimlane" is 14).

Suggested direction

Parts A and B together. All three of A's operations are stateless given a pointer to the action. Replace the three std::functions with a pointer to a static per-(Model, Action) vtable of free functions:

struct ActionOps {
    std::string (*serialize)(const void*);
    std::shared_ptr<void> (*deserializeResult)(std::string_view);
    std::shared_ptr<void> (*invokeLocal)(IModelHolder&, const void*);
    std::string_view modelTypeId;    // no allocation
    std::string_view actionTypeId;
};
template <class M, class A> inline constexpr ActionOps kOps{...};

ActionCall then holds const ActionOps* plus one type-erased action pointer: 5 allocations removed and the two string copies gone.

For B, the type erasure is needed because IBackend::execute is a non-template virtual — but it could live in the result rather than in the completion. Give IBackend::execute a void (*settle)(void* state, std::shared_ptr<void>) plus the typed state pointer, so the backend settles the caller's state directly. One state, one executor hop, one cast — and the forwarding .then at bridge.hpp:1571 disappears. What must be preserved: that forwarding block also cancels the client deadline, decrements _pendingCalls, and calls publishResult. Those need a home in the new shape.

With A and B folded together, a realistic target is 2-3 allocations per call against the measured 19.2.

Part C. Add a transparent hash and equality (is_transparent) so a std::pair<std::string_view, std::string_view> looks up with no allocation, and merge the four parallel maps into one unordered_map<Key, ActionEntry> so four lookups become one.

Coordination

This overlaps #567-#571, which is reshaping IBackend's registration surface and will delete its four *Async verbs. Part B changes IBackend::execute's signature. Sequence behind that set, or agree the split with whoever holds it — do not land a competing IBackend change.

Also recorded while here (from #529, not in scope)

ActionDispatcher and ModelRegistryFactory are process-wide singletons with no mutex (registry.hpp:687-690, :784). Registration is static-init-only in practice, which makes that safe today, but nothing enforces it — a dlopen'd plugin registering after threads start is a data race on the maps. Relatedly, registerActionOnce/registerModelOnce are declared noexcept (registry.hpp:800, :807) while allocating four map nodes and two strings, so bad_alloc at static init is std::terminate. Worth a documented precondition at minimum; file separately rather than folding in.

What would change the verdict

• Close A/B if 1.5 us and 2 KB per call are acceptable for the intended workloads — which for a desktop GUI they may well be. This is headroom, not a crisis. It is sharper on the server path, where the same executeVia shape runs per request.
• Close C if a measurement shows the ids are SSO-sized in practice and the lookup is not hot enough to matter. Raise it by profiling RemoteServer::handle under load and attributing time to find.
• Any fix must land against a recorded baseline. tests/bench/bench_dispatch_latency.json is produced but never diffed — an allocation-budget benchmark that is never compared is exactly the "control that measures nothing" failure AGENTS.md warns about. The acceptance criterion for this issue is a benchmark that fails when the budget regresses; prove it by reverting the fix and watching it fail.

[Yaraslaut]

Triage verdict: valid

Re-verified against 8858450d (current master), not the 4017228d the findings were measured at.

Every cited mechanism still exists. Line numbers moved (#577 added 489 lines to backend.hpp); the code did not:

• Part A — bridge.hpp:1466-1467 still constructs call.serializeAction and call.deserializeResult unconditionally, on every call, including when the backend is LocalBackend and will never use them.
• Part B — completion.hpp:35 and :165 still erase handlers as std::function<void(T)>, which is the mechanism behind the per-handler materialisation.
• Part C — the allocating key construction is at registry.hpp:477, 562, 577, 596, 642, 664. The issue named four sites; there are six. :477 and :642 were missed. This does not change the fix — it makes it slightly more valuable.

The four parallel maps are still at registry.hpp:687-690.

One thing that will invalidate the baseline, and it is imminent

PR #579 is open and rewrites completion.hpp's handler erasure — exactly the std::function<void(T)> at :35/:165 this issue attributes allocations to. The issue's own attribution says three of the 19.2 allocations are std::functions that cannot use libstdc++'s small-buffer path because they capture a shared_ptr. #579 changes that shape and measures the copy budget going from N + 2M to zero-per-const T&-handler.

So the 19.2 allocations/call figure is a pre-#579 number. Do not start this ticket against it.

Required first step: after #579 lands, re-run the global operator new counter from the issue and record the new baseline. If it has already fallen materially, Part B's scope shrinks and should be re-stated before anyone builds it.

Sequencing

Part B changes IBackend::execute's signature. #567 (PR #577) has landed and #568-#571 are still migrating that interface. Do not land a competing IBackend change — sequence behind #571 or agree the split with whoever holds it.

What would change the verdict

Unchanged from the issue: close Part A/B if 1.5 us and 2 KB per call are acceptable for the intended workloads, which for a desktop GUI they may well be. The acceptance criterion stands and is the important part — a benchmark that fails when the budget regresses, proven by reverting the fix and watching it fail. tests/bench/bench_dispatch_latency.json is produced but never diffed.

[Yaraslaut]

Not dispatched this sweep — file-tree contention.

The fix site named here is include/morph/core/bridge.hpp (executeVia, :1462-1470), and a concurrent lane holds that file while it resolves #593 — the registration-surface discriminator currently keeping PR #585 red. Two lanes rewriting executeVia and registerHandlerImpl at once produces PRs that invalidate each other, and at this repository's 26–74 minute CI cycles the rebases cost more than the parallelism buys.

Also relevant to sequencing: #593's fix changes how registerHandlerImpl acquires a binding, and Part A's measured 19.2 allocations-per-call figure was taken on master @ 4017228d. Re-measure before building against that number — if #593's fix moves work into or out of the registration path, the attribution in Part A may shift even though the totals were honestly measured.

Re-entry condition: dispatch once PR #585 lands, re-measuring Part A first. No change to the ticket is needed.

[Yaraslaut]

Re-measured on f24e225a. The total holds; the attribution does not, and the attribution is what scopes the fix.

Dispatched to be re-measured before anything was built, because #639, #649 and
#654 rewrote the dispatch path after the 4017228 figures were taken. Handing
the ticket back with the new numbers rather than building against them — the
per-call total is essentially unchanged, but three of the specific costs Part A
and Part B are scoped by are not what the ticket says, and the "2-3 allocations
per call" target is unreachable by A+B as written.

The instrument

tests/bench/bench_dispatch_allocations.cpp (target morph_bench_alloc,
-DMORPH_BUILD_LOAD_TESTS=ON) landed on the branch for #588 so this is
repeatable in one command. It replaces the global operator new/delete,
warms up 50 calls, counts 200, waits each round trip out, and prints per-call
totals; --attribute prints the size of every allocation in one steady-state
call. It is not registered with ctest and asserts nothing unless --budget=<n>
is passed — an allocation count is standard-library specific, so a fixed
ceiling would be wrong on the next toolchain.

The number

Revision f24e225a. x86-64 Linux, GCC 16.2.1 / libstdc++, -O2 -DNDEBUG.
struct BenchAllocPing { int x; } -> struct BenchAllocPong { int y; } through
LocalBackend on a one-thread pool with an inline callback executor — no JSON,
no socket.

local execute round-trips  : 200
heap allocations total     : 4165 (20.82 per call)
bytes allocated total      : 398912 (1994.6 per call)

allocations in one steady-state call: 21

Against the ticket's 19.2 / 1983: 20.8 and 1995. The premise holds in
aggregate — the path did not get cheaper, it got very slightly more expensive.

Where the 21 actually go

Backtrace-attributed, not read: the same program built -O2 -g -rdynamic with
a backtrace() in the counting hook, symbolised with addr2line -f -i -C
after subtracting the PIE load base. Sizes are the measured request sizes.
Line numbers are f24e225a's (i.e. before this branch's #588 commit, which
does not touch executeVia).

#	bytes	site	what
0	160	bridge.hpp:1520	make_shared<CompletionState<R>> — typed state
1	17	bridge.hpp:1578	call.actionTypeId string
2	24	bridge.hpp:1579	make_shared<Action>
3	16	bridge.hpp:1580	serializeAction std::function
4	16	bridge.hpp:1584	localOp std::function
5	176	backend.hpp:1218	make_shared<CompletionState<shared_ptr<void>>> — erased state
6	344	backend.hpp:1253	the strand task std::function
7	32	strand.hpp:104	_strands map node
8	152	strand.hpp:106	make_shared<Strand>
9	64	stl_deque	the Strand's queue map
10	512	stl_deque	the Strand's queue buffer
11	32	strand.hpp:150	scheduleNext's std::function
12	136	bridge.hpp:1686	the forwarding .then closure
13	32	completion.hpp:202	handler vector, erased completion .then
14	64	bridge.hpp:1788	the forwarding .onError closure
15	32	completion.hpp:221	handler vector, erased completion .onError
16	24	bridge.hpp:1635	make_shared<R>(model.execute(...)) — the result
17	32	completion.hpp:202	handler vector, typed completion .then
18	32	completion.hpp:221	handler vector, typed completion .onError
19	40	completion.hpp:108	settle task posted to cbExec (erased)
20	40	completion.hpp:108	settle task posted to cbExec (typed)

What that changes about the ticket

Confirmed. Two CompletionStates per call, exactly as Part B says (#0 and
#5). make_shared<Action> for a POD, as Part A says (#2).

Wrong: "2 strings". One, on this workload, and the reason is the SSO
threshold the ticket already applies to Part C but not to Part A. The
attribution run used "Probe_PingModel" (15 characters) and
"Probe_PingAction" (16): the 15-character one fits libstdc++'s 15-byte
short-string buffer and allocates nothing, so only call.actionTypeId
(bridge.hpp:1578) shows up. The committed bench has the same property with
the lengths swapped ("BenchAlloc_Model" 16, "BenchAlloc_Ping" 15) and
likewise shows exactly one 17-byte string. So the string cost is 0, 1 or 2
per call depending on how long the ids are — for the ladder's own ids
("CreateSwimlane", 14) it can be zero. Part A's "the two string copies gone"
is therefore worth 0–2, not 2.

Wrong: "3 std::functions, each capturing a shared_ptr". Two.
call.deserializeResult (bridge.hpp:1581) is captureless, so libstdc++
stores it in the small buffer and it allocates nothing. It does not appear in
the census at all.

Unrecorded, and it is the largest single cluster: the strand churn. #7–#10
are four allocations and 752 of the 1995 bytes — 38% of the bytes per call
— spent creating a StrandExecutor::Strand (map node, control block, and the
std::queue's two deque allocations) that is then destroyed again. It is
per-call rather than per-model because scheduleNext erases the map entry
whenever a strand drains empty (strand.hpp, the drain-and-erase block), so a
serial workload allocates a fresh strand for every dispatch. The ticket names
only "a possible make_shared<Strand>" in passing. Filed separately as #660
rather than folded in here, per AGENTS.md.

Why this is a hand-back and not a fix

The ticket's acceptance is "a realistic target is 2-3 allocations per call
against the measured 19.2". Against the measured breakdown:

• Part A removes Message queue #3, tests: add coverage-gap tests to lift branch/partial coverage #4 and 0–2 strings: 2–4, not 5. [morph] Add bank example: models, tests, CLI, Qt 6 GUI, relations + WebAssembly demo #2 (make_shared<Action>)
  cannot go — the action must outlive the caller's frame — unless it moves into
  the same allocation as something else.
• Part B, collapsing the two states into one, removes Add an ordered, coalescing, identity-aware action log #5, Spec-audit remediation: correctness fixes, hardening, spec updates #12, feat: enable strict compilation with maximum warnings as errors #13, ci: add header ↔ spec sync gate #14, test: spec-sync gate self-test (do not merge) #15
  and one of Production-hardening + GUI enhancement program (28 items) + 2 security fixes #19/Stateful models: keyed shareable instances, instance subscriptions, and a bank example that demonstrates them (closes #18) #20: ~6.
• That leaves 11–13 per call, not 2–3, because the remaining cost is the
  strand churn (4), the strand task closure (Add exact Rational/Quantity value types and schema-driven form generation #6), the result make_shared
  (fix(tests): rename ~Bridge test so ctest runs it in isolation #16), the typed completion's own two handler vectors (refactor: group headers and specs into sub-domain folders #17, Other similar solutions #18) and one
  settle task — none of which A or B touches.

So building A+B as scoped would be work measured against a target it cannot
reach, and the most valuable single item on the list is not in the ticket at
all. Part B is also still an IBackend::execute signature change, which the
first triage comment already sequenced behind the #567–#571 set.

Suggested re-scope, for whoever picks this up:

1. The strand churn (core: StrandExecutor rebuilds a model's Strand on every serial dispatch -- 4 allocations and 752 of the 1995 bytes per local call #660) first — the largest byte saving, no public
   interface change, no IBackend coordination.
2. Part A, re-stated honestly as 2–4 allocations with an SSO caveat on the two
   type-ids.
3. Part B unchanged in substance but with its own number: ~6, and the biggest
   single win, at the cost of an IBackend::execute signature change.
4. Replace the "2–3 allocations per call" target with one derived from the
   above, or drop the target and keep the acceptance criterion (a budget that
   fails on regression) — which morph_bench_alloc --budget=<n> can now
   express, though it needs a per-toolchain number before it can be a CI gate.

Not verified

• Part C was not re-measured. It is the server-side ActionDispatcher
  path; this census only covers Bridge/LocalBackend. Its "two strings per
  server dispatch" claim is untouched by this comment, in either direction.
• One toolchain, one platform, one workload. libc++ and MSVC have different
  SSO thresholds and different std::function small-buffer sizes, so both the
  string count and some of the 16–40-byte closures will differ there.
• The per-call time figure (1.5 µs, 654k calls/s) was not re-measured.
• core: stop a cancelled control call reaching the wrapped backend, and pin parkIfInFrame's unreachable double-claim arm (fixes #636, fixes #648) #654's per-call PendingControl does not appear here, and should not:
  SynchronousBackendAdapter reshapes bindModel/promoteModel only, so its
  allocation is per control call, not per execute. Reading the code, not
  measured — no SynchronousBackendAdapter is in this census's path.