The latest published paired comparison (2026-08-07) does not show Wurk ahead of stock Sidekiq. These are historical measurements, not a current-release guarantee. A re-run on 2026-11-03 at a later commit does not either.

Two different benchmark suites live in bench/. They answer different questions and only one of them compares against Sidekiq.

The regression check can be fully green while wurk is slower than Sidekiq. It measures wurk against its own past self. Do not read rake bench as a competitive result.

wurk 1.4.0 · sidekiq 8.1.6 · ruby 3.4.7 (x86_64-linux) · local Redis 7.4.10 · 5000 jobs/run · 12 runs per topology (4 invocations × 3 runs), paired per-run ratio (wurk_i / sidekiq_i within the same run, which cancels drift a median-of-medians would carry). Measured 2026-08-07, the latest published paired comparison; these results describe those engine versions and that environment, not a current-release guarantee. Reproduce with bin/rake bench:vs_sidekiq.

Ratios below 1.00 mean wurk is slower.

1 process × 5 threads

4 processes × 5 threads — wurkswarm (4 forks) vs 4 independent sidekiq processes

Boot to first job, median over all runs per side:

In that published comparison, Wurk was at parity with stock Sidekiq on cpu and io at both topologies. It was still behind on noop — pure framework overhead, where the extra Redis commands below cost the most — and on boot. This is a large move from the numbers this doc previously published (noop 0.45×/0.49×, cpu 0.81×/0.86×, io 0.74×/0.66×), but it is not a "faster than Sidekiq" result; see Status.

Forking does not close the gap. A stock Sidekiq user reaches multi-core by running N processes — that is the second table. The swarm's advantage is copy-on-write memory and a single supervisor, not throughput.

The run carried unrelated background load on the host for part of the session, which is why the per-invocation spread (min/max above) is wide — the paired-ratio median is the number to trust, not any single run. Full per-invocation record: docs/plans/2026/08/06/101-faster-than-sidekiq/08-measurements.md.

The same harness at a later commit: the 1.10.0 code plus the change below, stock Sidekiq 8.1.6, ruby 3.4.7 without YJIT, local Redis 7.0.15, 5000 jobs/run, 12 paired runs per topology. Ratios below 1.00 mean Wurk is slower. Q1 and Q3 are the quartiles of the 12 paired ratios. The host carried light unrelated load (load average 2 to 4). The tables above stay the published headline until this is republished with its raw record.

Boot to first job, median: Sidekiq 0.54s and Wurk 0.70s at 1 process, Sidekiq 0.54s and Wurk 0.73s at 4. Wurk is the slower one. cpu and io are within about 3% of Sidekiq, noop and boot are still behind, and this is not a "faster than Sidekiq" result. The harness hand-builds its payloads, so the change below is not on its clock: a difference from the published tables is a difference of host and commit.

Same args, single thread, Redis on loopback, 10 paired rounds, wall time per job. 1.10.0 is an identical copy of the code before the change below; the A/A column compares a second such copy to it.

push_bulk was 2.2× slower than Sidekiq and is now 1.4× slower. perform_async did not change and is still behind.

"Faster" is meaningless without naming the work. Three shapes, all in bench/vs_sidekiq/job.rb:

cpu is the noisiest shape (min/max spans 0.67×–1.41× across the 12 paired runs above). Single runs of it mean nothing — only the paired-ratio median across many runs is worth reading.

Redis commands per job, counted with INFO commandstats over 500 jobs. Reproduce with bin/rake bench:command_count, which prints the breakdown below and is the source these numbers are published from:

wurk — 500 noop jobs drained from queue:default (INFO commandstats)

  commands  per job  command
       500     1.00  lrem
       500     1.00  lmove
       500     1.00  del
  --------  -------
      1500     3.00  total

3.00 commands/job, at budget and at the recorded baseline — down from the ~10 commands / 4 round trips this doc previously published. What is left, and the verdict on it:

• Reliable fetch — the same one round trip per job as BRPOP, with three commands inside it rather than one. This is Wurk::Fetcher::Reliable, the default. Sidekiq's equivalent (super_fetch) is a paid Pro feature; stock Sidekiq's BRPOP loses in-flight jobs when a worker is killed. The extra commands buy a guarantee, and are not a defect. Note the table counts commands, not round trips — INFO commandstats cannot see a pipeline.
• The poison-pill DEL is a deliberate keeper, not an oversight — a reclaimed payload is byte-identical to a fresh one, so only the counter distinguishes them, and Lua can't fold this away. 3 commands/job is the settled floor; the plan's original ≤2 target is not reachable without dropping the poison-pill guarantee.

Costs that used to dominate this table are gone:

• Metrics were 6 of the old ~10 — Wurk::Metrics::History wrote 2 HINCRBY + EXPIRE per job, twice over. They are now folded in memory per (class, minute) and flushed every ≤5s, the same trade Sidekiq makes; see Write cadence for what that costs on a hard kill. A worker still pays one pipeline per Redis pool per flush, carrying 6 commands per (class, minute) bucket, which rounds to nothing per job at any real throughput and does not appear above.
• The paused SET was the seventh, an SMEMBERS on every fetch pass; it is now read at most once per PAUSED_TTL per fetcher.
• The ACK was a round trip of its own, sent the moment a job finished. Its LREM + DEL now ride the next fetch's pipeline — the same commands, one fewer round trip — at the cost of a wider window in which a hard kill re-runs an already-finished job.

noop is pure framework overhead, so it is exactly where 3 commands per job against Sidekiq's 1 still costs — it is the shape that has to cross 1.0× before wurk stops being behind here at all.

Global per-queue concurrency capping (config.global_concurrency, 10-global-concurrency.md) shipped without moving this table. Unconfigured, Wurk::Fetcher::Capped resolves a boot-time boolean and falls straight through to the same Reliable loop counted above — still 3.00 commands/job, and rake bench unconfigured stayed within noise of main across the whole gate (enqueue, fetch+execute, bulk enqueue, swarm boot, memory) — see the slice doc's ship decision for those numbers.

A queue that is capped pays for it, honestly, and that cost has not been benchmarked: fetch_slot.lua folds the gate into the fetch so a capped queue spends the same one round trip an uncapped one does, but its script runs TIME, ZREMRANGEBYSCORE, ZCARD and ZADD around the LMOVE, and nobody has put an i/s number on that. 10-global-concurrency-measurement.md is not that number — it is the pre-implementation prototype, which priced the bracketing shape (a bare acquire and release around the fetch, 2.2x–2.6x) that the real implementation exists to avoid. Read it as the upper bound it is.

Round trips are the headline, but they are not the whole bill. Once the fetch pipeline was down to one round trip, the next-largest movable cost was the Ruby that runs between conn.call(...) and the socket. bin/profile samples it against a real Redis:

bin/profile                 # fetch+execute, CPU samples
bin/profile enqueue         # the client push path
bin/profile fetch --alloc   # allocation counts, for GC pressure

What that turned up, and what was done about it. Percentages are that frame's share of a 50k-iteration fetch+execute CPU profile, before → after:

About 6% of the profile, on a path where roughly a quarter of it is socket syscalls that no amount of Ruby can remove. The same three changes move bench/memory.rb — the one gate here that is deterministic rather than wall-clock, since it counts allocations — from 6.49 to 6.76 jobs per 1,000 allocations, about 4% fewer allocations per job. The throughput benches also improved on the same machine, but not by an amount worth publishing: this host was under unrelated load for the "before" run, and a paired re-measurement against stock Sidekiq has not been done since. The vs-Sidekiq table above is therefore unchanged and still the number to quote.

• Command normalization was 4.4% of fetch+execute. redis-client's default builder splices Hash arguments with a flat_map and stringifies the result with a map! — two array allocations and two per-element type dispatches for a command whose arguments are already Strings, which is what all three commands per job are. Wurk::CommandBuilder short-circuits that case and hands anything else (a Hash to splice, a Symbol or number to stringify, kwargs) straight to redis-client's own builder, so the semantics have exactly one implementation. The 1.7.0 release notes report ~2.1µs → ~0.48µs per command, a historical measurement, not a new timing run here. Reproduce with bin/rake bench:command_builder. The ACK's LREM count is a pre-stringified '1' for the same reason — one Integer argument would send the whole command back through the slow path. The shortcut has one trap worth naming: redis-client splats **kwargs before calling the builder, so a call with no keywords arrives with an empty Hash, never nil. A guard that only tested .nil? sent the whole hot path down the slow branch while every output-equality test still passed — which is why Wurk::CommandBuilder.fast? is public and asserted directly.
• Process.pid was 1.0%. glibc dropped its getpid cache in 2.25, so it is a real syscall — ~640ns — and the hot path called it twice per job (Component.tid and the fetcher's per-queue key cache, both of which read it only to notice a fork). Wurk::PidCache memoizes it and refreshes in the child half of every fork via Process._fork, which is the only event that can change the answer.
• JobLogger#context_hash re-read config[:logged_job_attributes] through the capsule's delegating [] on every job, to walk a list that is fixed once the configuration freezes at launch. Read once, in the constructor.

And the cost paid before the first job runs at all — require "wurk", which is boot time for every worker, every fork in a swarm, and every Rails app that loads the gem. It was ~290ms; it is now ~186ms. Three subtrees were pulling heavy stdlib in eagerly for code most processes never reach:

Each is now required inside the one method that uses it. require is idempotent, so every call after the first is a $LOADED_FEATURES hash lookup. What remains is dominated by openssl (~58ms), which redis-client's own config requires and Wurk cannot avoid.

None of these change a Redis key, a command sequence, or a job-JSON field — they are the same wire traffic with less Ruby in front of it. bench/command_builder.rb is in the advisory regression check so a fast path that stops firing can be flagged in the PR comment. The benchmark job is not a required check and does not block merges.

Each candidate ran against an identical copy of the code, next to an A/A control that compares a second copy to it. That control is the noise floor.

What shipped touches push_bulk only: no code on the path a worker runs changed.

bin/rake bench:vs_sidekiq                            # 1 proc × 5 threads
WURK_BENCH_VS_PROCESSES=4 bin/rake bench:vs_sidekiq  # swarm vs 4 sidekiq procs

Needs a local Redis. First run installs bench/vs_sidekiq/Gemfile (stock Sidekiq, isolated bundle).

WURK_BENCH_VS_SHAPE and WURK_BENCH_VS_DONE_KEY are set by the driver in each child worker's environment (bench/vs_sidekiq/child_env.rb) — read by bench/vs_sidekiq/job.rb, not set by hand.

bin/rake bench runs the harnesses the regression check reads. Each takes its size from the environment, so a slow laptop can shrink a run without editing the harness:

bin/bench-compare BASELINE.txt CURRENT.txt prints the per-benchmark delta and is what fails the bench vs base check:

A drop is flagged only when drop% > base_err% + head_err% + BENCH_REGRESSION_PCT, so two ±7% samples differing by ~14% with no code change do not block a merge. Speedups are always reported and never gated.

The comparison is only worth reading if the control is real. What the harness guarantees:

• Stock Sidekiq is actually stock. Wurk ships lib/sidekiq.rb (the drop-in require shim) and Bundler puts every bundled gem's lib/ on $LOAD_PATH — so inside the repo bundle, bundle exec sidekiq boots wurk. The Sidekiq side therefore runs from bench/vs_sidekiq/Gemfile with RUBYOPT and RUBYLIB cleared. The two distinct versions printed in the header are the proof; identical versions mean the run is void.
• Identical job code. include Sidekiq::Job resolves to wurk's compat module on one side and the real gem on the other. Same file, both sides.
• Identical payloads. Jobs are hand-built into the shared Redis key schema and pushed by the driver, so neither side's client library is on the clock.
• Boot excluded from the rate. Throughput is measured over drain (first completion → last). Boot is reported separately, never folded into the rate.
• Alternating runs. Sides alternate tightly so thermal drift and background load hit both engines evenly.

The claim "faster than Sidekiq" has been removed from the README and the site, and may not be added back until the numbers above support it — they do not yet (CLAUDE.md pillar 3).

The Metrics::History batching and the ack piggyback that closed the round-trip gap have both landed and are reflected in the numbers above — four round trips per job down to one, and ~10 commands down to 3 — at the cost of dashboard counters lagging by the flush interval, a hard crash dropping the unflushed window, and a wider window in which a hard kill re-runs an already-finished job. The throughput and command-count tables above are re-measured post-landing, not carried over from before that work.

Published result (2026-08-07): wurk was at parity with stock Sidekiq on cpu and io at both topologies measured, and still behind on noop and on boot to first job. Not a "faster than Sidekiq" result. Full per-invocation record and the verdict against the plan's "done when" criteria: docs/plans/2026/08/06/101-faster-than-sidekiq/08-measurements.md. The 2026-11-03 re-run changes the ratios, not the conclusion.