Performance SLOs

Overview

PCP defines strict performance targets for every stage of the intent lifecycle. These are not aspirations; they are service-level objectives that the CI pipeline enforces. A commit that regresses any metric beyond its maximum acceptable value fails the build. The benchmark suite runs on every commit and reports P50, P99, and maximum latency across all three privilege domains.

Budgets are set for the socket topology: measured point-to-point on the target hardware. ARM validation discipline still applies before tightening any number. Benchmarks run via the pcp-stream test suite.

Latency Budgets

Each stage in the execution pipeline has a target latency and a hard maximum. The target represents normal operation on the reference hardware. The maximum is the boundary beyond which the system is considered degraded.

Metric	Target	Maximum	Notes
IPC frame encode + decode (16 KiB JSON)	< 0.5 ms	1 ms	Measured in pcp-stream tests
RegistryQuery (capabilities) round-trip	< 10 ms	25 ms	In-memory dashmap read
ExecuteRequest (Tier 1, in-process runtime)	< 20 ms	50 ms	Trait-object call
ExecuteRequest (Tier 1, app socket)	< 50 ms	100 ms	Includes postcard + JSON serialization
ExecuteRequest (Tier 2, AT-SPI2)	< 100 ms	200 ms	D-Bus round-trip dominates
Tier 1 manifest fetch + Ed25519 verify	< 50 ms	100 ms	Startup budget
Event delivery (AT-SPI2 to subscriber)	< 500 ms	–	Event streaming goal
Rate-limited rejection	immediate	–	429 before dispatch

The Tier 1 split matters. In-process runtime calls (trait-object dispatch within the same process) are fast because they avoid serialization and IPC entirely. App socket calls cross a Unix domain socket, adding postcard encoding, JSON conversion, and kernel context switches. The budget accounts for all of that.

Tier 2 AT-SPI2 calls are the slowest path. D-Bus round-trip latency dominates, and there is no way to avoid it for apps that lack native PCP support. The 200 ms maximum reflects realistic D-Bus latency on reference ARM hardware.

Event delivery has a soft target of 500 ms. Unlike request-response paths, event delivery is asynchronous and not directly user-facing. The 500 ms budget exists to prevent stale state from accumulating in subscribers.

Startup Performance

Startup targets cover the time from daemon boot to full operational readiness.

Metric	Target	Notes
Daemon cold start to IPC socket bound	< 1 s	Socket must be accepting connections
Static Tier 1 detection (full registry)	< 2 s (warm), < 5 s (cold)	Scans installed .desktop files and ELF manifests
Detection cycle	30 s periodic, 5 min forced rescan	Ongoing after initial boot

Cold start means the daemon is launching from scratch with no cached state. Warm start means the daemon was recently running and some detection state may be cached. The cold start budget of 5 seconds for static Tier 1 detection covers a full scan of installed applications, manifest loading, and Ed25519 signature verification.

The periodic detection cycle at 30 seconds catches newly installed applications and capability changes. The forced rescan at 5 minutes provides a safety net if the periodic cycle misses something.

Memory Budgets

Every component has a per-instance and total memory budget. The overall PCP memory footprint must stay under 128 MiB.

Component	Per-Instance Budget	Total Budget
Capability registry entry	< 4 KiB	(varies by app count)
Capability manifest (Tier 1)	< 64 KiB	1 MiB
Audit log ring buffer	(not per-instance)	50 MiB
In-memory registry + bus	(not per-instance)	bounded by daemon RSS
Total PCP memory		< 128 MiB

The audit log ring buffer is the single largest consumer at 50 MiB. It uses a fixed-size append-only buffer with chain integrity verification. When the buffer fills, older entries are evicted but the chain remains verifiable.

The daemon’s own RSS is bounded by its service manager unit. Hosts using the supervision library enforce budgets programmatically via MemoryBudget and TrackingAllocator.

Production Monitoring

In production, three alert thresholds trigger automatically:

• P99 latency exceeds the maximum acceptable value for 5 consecutive minutes.
• Memory usage exceeds 80% of the total budget.
• Warm startup exceeds 5 seconds.

These alerts feed into the daemon’s health monitoring system. They do not block user actions, but they indicate that the system is operating in a degraded state and may need attention.

Benchmarking

The benchmark suite runs via pcp bench --full. It uses synthetic intents that exercise all three tiers, measures latency at each pipeline stage, and reports memory usage. Benchmarks are integrated into CI and must pass before any commit merges.

A CI failure from a performance regression blocks the commit. The developer must either fix the regression or provide a documented justification for the new baseline.