Phase A: Client (1 worker)

Pure-Go client at the final tree against its predecessor and against Apple’s Go binding over libfdb_c 7.3.77. One closed-loop worker, 11 workloads, counterbalanced. Part of the hcloud-rebench-20261014 campaign, which lists the other phases.

Arms

Executables: //tools/clientbench/cmd/clientbench:clientbench_go (per tree) and :clientbench_cgo, harness d94b4c61377d173b7c6884fde426a227dab0f0bb (tools/clientbench, docs/benchmarks/campaign-harness.md).

Environment

• Hetzner ccx43, fsn1: 16 dedicated vCPUs (AMD EPYC Milan, 8 cores × 2 SMT threads, one NUMA node), 64 GiB. Guest CPU groups by sibling pairs: housekeeping/runner 0–1, fdbserver 2–7, client 8–15. Guest affinity is not physical-host isolation.
• One fdbserver 7.3.77 process, single redundancy, ssd-2 engine, API 730. The client ran in a network namespace with no default route, reaching the server over a private veth pair on the same host. No artificial delay.
• Go 1.26.9, GOMAXPROCS=8, GOGC=100, GOMEMLIMIT=off, empty GODEBUG.
• Every run’s quiescence gate, CPU-steal/OOM/server-health telemetry and pinned input hashes passed. All 11 workload campaigns completed; none was rerun.

Design

• Per workload: 6 balanced blocks, each running all three arms once in a preregistered order (seed 641001; every arm order appears once). One fresh process per run: 200 warmup then 3,000 measured transactions, so 18,000 measured transactions per arm and workload, 594,000 in total.
• Workloads: grv (read version only), get100/get1000/get10000 (one point read of a 100 B/1 kB/10 kB value), read1000 (point read in a read-only transaction), range10/range100 (one range read of 10/100 rows), set100 (one 100 B write and commit), ryw (write then read the same key in a transaction that is never committed: no server round trip), batchset50/batchset50x1000 (50 writes of 100 B/1 kB and one commit).
• Estimands: per-run statistics; the paired effect is the geometric mean of the six within-block ratios, with a nominal 95% percentile bootstrap over blocks (20,000 resamples, seed 391706). Absolute values are medians of the six run-level statistics. No outliers were removed.
• CPU scopes. Shutdown process CPU (E−A) is the process’s user+system CPU from after binary identity hashing to after measurement, finalizer drain, database close and native network stop, divided by measured transactions. It includes startup, fixture, warmup and validation, so it charges each client for work the measured window can hide (deferred GC, native threads). Go bytes/mallocs per transaction count the Go heap only; the native libfdb_c heap is unobserved, so they are not comparable with the CGo arm.

Results

Final pure-Go vs CGo

Ratio final/CGo (below 1 means pure-Go is faster or cheaper), nominal 95% interval.

Final vs before pure-Go: the allocation work

Ratio final/before.

Absolute values

Medians of six run-level statistics per arm.

Interpretation

What the data shows:

• Pure-Go was faster than CGo on every workload’s mean latency, with intervals below 1 everywhere except range100 (0.846, interval reaching 1.024). The gap is largest where the client’s own work dominates:
  • ryw (0.189): no server round trip at all. It measures transaction creation, a buffered write, a read served from the read-your-writes cache, and cancellation. Pure-Go took 9.7 µs mean, CGo 49.4 µs.
  • grv (0.515): one round trip to the GRV proxy, 217 µs vs 423 µs.
  • Point reads (0.613–0.651): one GRV plus one storage read.
• The absolute saving is about the same everywhere a round trip occurs, so the ratio shrinks as transactions get longer. CGo’s mean minus pure-Go’s was 0.17–0.25 ms on every workload except ryw (grv 0.21 ms, set100 0.22 ms, batchset50x1000 0.25 ms). Commits take 1.9–3.0 ms in total, so the same saving gives ratios of 0.897–0.931 there.
• Process CPU through shutdown (E−A) favored pure-Go on grv (0.659), read1000 (0.775), get1000 (0.858), the commits (0.863–0.887) and ryw (0.228). For get100, get10000, range10 and range100 the intervals include 1; range100’s point estimate is above 1 (1.101, interval 0.968–1.269).
• The allocation work cut Go allocations (final vs before): mallocs per transaction fell 3–20% on every workload, and bytes up to 18% (range100 0.824, range10 0.844). Latency did not change measurably: every mean-latency interval includes 1. CPU through shutdown was lower only for range100 (0.952, interval 0.937–0.971).

What the design suggests but did not isolate (hypotheses, not measured causes):

• The CGo arm’s extra latency is consistent with its per-call costs: each operation crosses the cgo boundary, and each result is delivered by libfdb_c’s network thread through a future callback to a waiting goroutine. The pure-Go client issues and completes requests on goroutines over Go’s network poller with no thread handoff. ryw is the cleanest view of this, since no network is involved; no profile attributed the time.
• Pure-Go’s narrower margin and higher CPU on range100 are consistent with materializing 100 key-value slices on the Go heap per read (about 50 kB and 75 mallocs per transaction), which the C++ client keeps in its arena. Go GC work is charged to E−A. This was not profiled.

Limits

• One host, no physical network. Server and client shared a host and talked over a veth pair, not a NIC, switch and real network path. A remote deployment adds network time that both clients pay alike, so it would most likely shrink these ratios toward 1; they are not a prediction for that case. The multi-node VPC design (tools/benchcampaign/multinode/) measures it.
• One worker, one process. Batching of read versions and commits, load-balancing across replicas, and cgo thread contention appear only under concurrency, which phase A does not test.
• One server process, single redundancy. No proxy/log/storage split, no replication, no cross-shard reads.
• Scopes. Latency is closed-loop per transaction, including retries (none occurred). E−A CPU includes startup and warmup; the Go heap figures exclude native memory. Intervals are nominal and per workload, with no correction for multiple comparisons and no aggregate across workloads.

Reproduction

The harness, plan sealing and adapter are in tools/clientbench and tools/benchcampaign/singlenode; docs/benchmarks/campaign-harness.md describes the benchmark sources. The raw per-run artifacts (plans, schedules, per-transaction samples, telemetry) and the analysis outputs are retained outside the repository with the campaign’s provenance receipts.