mar-cf
90d · built 2026-09-30
Performance
What mar-cf shipped in the selected window, measured in ETV, and how it compares with the 90 days before it.
Effective capacity
+31.8engineers
delivers like 32.8 (32.8x pre-AI)
Output (ETV)
4.6ETV
+1047.5% vs 0.4 prior
Features share
80.0%
+22.5 pp vs prior window
Fixes share
5.0%
+5.0 pp vs prior window
Work mix
80% Features10.9% Maintenance2.6% Tests1.5% Docs5% Fixes
16 commits over 90 days, ending 2026-09-30.
Daily performance
Daily ETV, stacked by Features, Maintenance, Tests, Docs and Fixes.
Repository spread
Where this developer's commits land. Concentrated work (top1 > 80%) vs polymath spread (top1 < 30%).
| Repo | Commits | ETV |
|---|---|---|
| foundations | 7 | 3.6 |
| workerd | 6 | 1.0 |
| cloudflare-docs | 1 | 0.0 |
Most impactful commits
Top 10 by ETV in the last 90 days.
- 2.4ETVAdd user-facing tracing pipeline Adds a user-facing span pipeline to `foundations`, parallel to and independent of the existing internal tracing pipeline. Application code emits spans into a separate harness that exports OTLP over HTTP on a Unix domain socket, with per-trace routing metadata (an application-defined `RoutingMetadata`) attached to each span and carried to the endpoint in a configurable header, plus W3C `traceparent` continuation in and out. The public API lives in a dedicated `tracing::user_tracing` module that mirrors the top-level internal-tracing functions (`start_trace`, `span`, `add_span_tags!`, ...), plus a top-level `dual_span` that records into both pipelines at once; `#[span_fn(user = true)]` emits a dual span. The user span rides on `TelemetryContext`, so it propagates across `.await`, spawns, and hooks without manual threading. Two rules shape the surface: the user and internal pipelines are fully independent (separate harnesses, scope stacks, and exporters), and the public surface speaks W3C. Sampling is not configured inside foundations -- per-request activation is driven by the caller. Everything is gated behind the `user-tracing` cargo feature.github.com-cloudflare-foundations · 68988e2b · 2026-07-16
- 0.8ETV[build] Update to V8 15.3.76.7 Rebase the workerd patch stack and update ICU and Perfetto to the revisions specified by V8. Refresh the TSan and Perfetto patches for V8 15.3, including the dependency configuration required by Perfetto v58.2. Rework the ExtendedMap Windows layout fix for V8 15.3. Move JSInterceptorMap's non-tagged flags and padding into ExtendedMap so Torque and C++ offsets stay aligned under MSVC without changing the object size or GC boundary.github.com-cloudflare-workerd · 9027667b · 2026-08-28
- 0.5ETVfeat(telemetry): add deferred user span activationgithub.com-cloudflare-foundations · 4b61a952 · 2026-09-03
- 0.5ETVAdd an owned UserSpan handle for user tracing The user-tracing API is built around an ambient scope stack: `span()` parents under whatever is current and hands back an RAII guard that pops on drop. The scope stack is a `ThreadLocal` and its guard is deliberately `!Send`, so a span can never be held across an await point. That model can't express a per-request span in a service whose request pipeline is a state machine of separate callbacks rather than a call tree. The span outlives every individual callback, so there is no lexical scope for it to live in, and the only `Send` escape hatch available today is `into_context()` — which is meant for propagating into a future, and drags a snapshot of the whole ambient `TelemetryContext` along with it. `UserSpan` is an owned, `Send` handle to a user span, detached from the scope stack. It can live in a struct field, cross threads, and be finished in a different callback from the one that started it. The span is reported when the last reference to it drops. That is normally the handle, though `enter()` takes its own, as does any context built from the resulting scope. Parents are named explicitly rather than inferred from a stack, because spans in a callback-driven pipeline overlap without nesting: an upstream fetch can still be unfinished while response-side work that is not part of it is running, so "innermost active span" is the wrong parent. A handle is always usable — there is no `Option`. When no trace is active, or it wasn't sampled, or no pipeline is configured, the handle is inactive: tagging does nothing, children are inactive in turn, nothing is reported. This keeps `if let Some(span)` out of call sites, and mirrors how cf-rustracing's own inactive spans already behave. `user_tracing::start_trace` and `w3c_traceparent` are re-expressed on top of the new type, and `create_user_span` now shares its child-construction with `UserSpan::child`, so each behaviour has a single implementation. `enter()` bridges back to the ambient API for callers that prefer it. Purely additive: no existing caller changes. `Tag` is now re-exported, since it appears in the `set_tags` bound.github.com-cloudflare-foundations · b4c910aa · 2026-08-11
- 0.1ETVrefactor(telemetry): distinguish deferred user spansgithub.com-cloudflare-foundations · a968d68d · 2026-09-03
- 0.1ETVAdd SpanContext::toTraceparent()github.com-cloudflare-workerd · 20e92f41 · 2026-08-08
- 0.1ETVfeat(telemetry): attach user spans to contextsgithub.com-cloudflare-foundations · c47af8c9 · 2026-09-03
- 0.0ETVCentralize TraceContext construction Route IoContext::makeUserTraceSpan() through the existing parent factory instead of assembling local span builders independently. Restrict populated TraceContext construction with kj::Badge<TraceContextParent> so the parent factory is the sole assembly point.github.com-cloudflare-workerd · 1cc4c585 · 2026-09-25
- 0.0ETVCorrect the UserSpan lifetime docs The type claimed the span is reported when the handle is dropped. It is reported when the last reference dropsgithub.com-cloudflare-foundations · 74ab2c7a · 2026-08-12
- 0.0ETV[build] Disable preserve_most on affected Windows Clanggithub.com-cloudflare-workerd · d6c57794 · 2026-08-31