Roundhouse benchmark results — campfire

Methodology. AMD Ryzen 5 3600 6-Core Processor, 6c/12t, 3.6 GHz, boost disabled, governor=performance, 63 GB RAM, Ubuntu 24.04.5 LTS. Toolchains pinned via mise. Harness: scripts/bench-campfire — workers=1, c=16, 3×20s runs per cell after 20s warmup; the median of the 3 runs is reported (the run-to-run spread is in the stability section below). Quiet machine throughout. Full hardware, toolchain versions, and the exact invocation are in the environment appendix below.

rails and the emit lanes BOTH serve campfire's message fragments from a cache — Rails from Redis (cached: true), the emitted tree from its own process-local store — so the deployed lanes compare like with like. Until 2026-09-07 the emit had no fragment cache and this page carried a rails-nocache column so the comparison was renderer against renderer rather than emit against Redis; that column is now a diagnostic, requested by name, and is not published here.

The deployed lanes are what each project would run on this box. rails is once-campfire AS ITS OWN DOCKERFILE RUNS IT: Thruster in front of Puma, (processor_count * 0.666).ceil workers x 5 threads from its own config/puma.rb, jemalloc preloaded, resque-pool alongside. ruby is the CRuby emit in the same Puma shape with the same allocator; spinel is the binary with its workers autodetected.

ruby IS A MATCHED-SHAPE RUNTIME COMPARISON, NOT A DEPLOYMENT CLAIM. It runs Rails' worker count so the number is not a core count, but the emitted tree's Action Cable registry and its job queue are both in-process: at more than one worker a broadcast reaches only the subscribers sharing a process with the poster, so campfire could not actually run this shape. Its deployable CRuby shape today is one worker — the ruby-1p row, read it against tobi for the deployable comparison; one process serving every core (Falcon on Ractors, the shape spinel already has) is the planned replacement. spinel needs none of this: one process, green threads, one shared registry — which is why it is the emit lane the WebSocket tier can measure at its full worker count.

ruby-falcon is the SAME emitted tree and config.ru as ruby, served by Falcon (the emit's falcon.rb: forked workers, the same count and allocator, cache hits answered ahead of Falcon's Rack adapter) instead of Puma: the server tobi runs. It isolates what the app server costs. Falcon is added to the emit's bundle by this harness, at the version tobi's lock pins; the emitted Gemfile names only Puma, and the WebSocket phase still runs Puma.

The -1p lanes are the diagnostic, and what they pin is ONE CPU rather than one process — CRuby needs a process per core because of the GVL, while the binary is a single process either way and varies its OS worker count instead (SPINEL_WORKERS=1). They exist because a deployed number cannot say WHY it landed where it did, so these rows separate "their runtime is slower" from "we gave them fewer cores". Read them per lane-family: ruby and spinel differ from their -1p twins in worker count and NOTHING else, but rails-1p also sheds Thruster and resque-pool, so its delta is not attributable to cores alone. ruby-1p is ALSO the emit's deployable CRuby shape: one Puma worker, so one cable registry and one job queue, the shape the WebSocket tier runs it in.

Known omissions, stated rather than discovered: the WebSocket phase's rails lane runs Puma with campfire's worker count and its allocator but WITHOUT Thruster and resque-pool, and no lane terminates TLS.

MEMORY IS THE SERVER PROCESS TREE, and the rails lanes keep part of themselves outside it. Their fragment cache, their Action Cable adapter and Resque's queue all live in a system Redis (~16 MB RSS here) that is nobody's descendant and so is in no lane's number — while the emit lanes hold their equivalent inside the measured process. Throughput is unaffected: the rails lanes pay for every Redis round trip in their req/s. Counted for rails: Thruster, the Puma master and its workers, resque-pool and its workers.

tobi is tobi/campfire-once-ruby-ractor: campfire ported BY HAND to plain Ruby, no Rails, served by Falcon from worker Ractors in one process, with in-process job and cable Ractors. It is the measured answer to "how fast can careful Ruby serve this app", and the target for the emitted ruby lane. It reads the same seeded database. Its deliberate differences from Rails (header-only CSRF, so its pages carry no tokens; part-hashed ETags; fewer cookie writes) are listed in its README.

The CRuby fragment store is PER PROCESS, so the ruby lane holds one cache per worker where spinel holds one for the whole binary.

spinel runs the same Roundhouse-emitted framework as the CRuby ruby cell, but compiled by Spinel behind its thread-per-connection server (a green thread per connection on the runtime's autodetected OS worker count) rather than CRuby + Puma — so the ruby → spinel gap is a runtime swap, not a framework or source change.

Incomplete run. 6 of 6 requested targets produced numbers:

• spinel stopped answering partway through its cells (21 of 22 timed runs recorded): server killed by SIGSEGV (status 139)
  last lines of its log

  [gcph] trim: 841 requests, 1 run inline (0.000s), trimmer thread on [gcph] slab release: 6093037 releases walked 353490947 chunks, handed back 8071265 (madvise 68.814s, sort 18.838s) [gcph] mark: roots 1.147s  fibers 0.121s  globals 33.494s  scan 57.571s

Every chart and table below is drawn from the targets that were measured; a target that failed to build is absent, not slow. Where a lane reached the run and then produced no numbers its cells are shown as no data, not as zero — an unmeasured cell means wrk found nothing serving, or found a server answering with errors (a cell with any non-2xx response is not a measurement of the endpoint — an error page is cheap to serve), which is a different claim from a runtime that was measured and is slow. Such lanes are left out of the derived charts (multipliers, RSS ranking) for the same reason.