Performance

go-ruby-ipaddr/ipaddr is the pure-Go library that rbgo binds for Ruby’s ipaddr. This page records the methodology for the comparative benchmark of that module against the reference Ruby runtimes, part of the ecosystem-wide per-module parity suite.

What is measured

The same Ruby script — a representative IPAddr workload — is run under every runtime. rbgo’s number reflects this pure-Go library doing the work; every other column is that interpreter’s own ipaddr stdlib. So the comparison is the Ruby-visible operation, apples-to-apples across interpreters. The script prints a deterministic checksum and its output is checked byte-identical to MRI before timing.

• Method: best-of-N wall time (best, not mean, to suppress scheduler noise); single-shot processes, no warm-up beyond the script’s own loop.
• Runtimes: ruby (MRI, the oracle) and ruby --yjit; jruby (OpenJDK); truffleruby (GraalVM CE Native).
• The benchmark script and harness live in rbgo’s repo under bench/modules/ (ipaddr.rb + run.sh). Reproduce: RBGO=./rbgo TRUFFLE=truffleruby bash bench/modules/run.sh 5.

Result (best of 5, ms)

rbgo runs on go-ruby-ipaddr at near parity with MRI (1.91x) on this parse + subnet-membership + range workload.

Library-level benchmark (Go API vs runtimes) — 2026-07-03

This section measures the pure-Go library directly, through its Go API — not the rbgo interpreter path recorded above. It isolates the library primitive from Ruby-interpreter dispatch, answering the parity question head-on: is the pure-Go implementation as fast as the reference runtime’s own ipaddr? The same workload, same inputs, same iteration counts run through the Go library and through each reference runtime’s stdlib; outputs were checked identical to MRI before any timing (to_s, the include? boolean, the masked address and the to_range endpoints all byte-for-byte equal — verified across MRI, JRuby and TruffleRuby too).

• Host: Apple M4 Max (Mac16,5, arm64), macOS 26.5.1 — date 2026-07-03.
• Runtimes: Go 1.26.4 · MRI ruby 4.0.5 +PRISM · MRI + YJIT · JRuby 10.1.0.0 (OpenJDK 25) · TruffleRuby 34.0.1 (GraalVM CE Native).
• Method: each process runs 3 untimed warm-up passes, then 101 timed passes (OUTER=101) of a fixed inner loop, timed with a monotonic clock; the best pass is reported as ns/op (lower is better). vs MRI < 1.00× means faster than MRI. Interpreter start-up is outside the timed region, so these are operation costs, not ruby file.rb process costs.
• Fixed inputs: IPv4 network 192.168.0.0/16, IPv6 network 2001:db8:85a3::8a2e:370:7334/64, IPv6 address 2001:0db8:0000:0000:0000:ff00:0042:8329, membership host 192.168.1.100, mask source 192.168.15.7 masked to /24.

include

mask

parse-v4

parse-v6

to_range

to_s-v6

Every operation now beats the reference, including the MRI + YJIT column. The earlier version routed every address through math/big (to handle IPv4 and IPv6 uniformly at arbitrary precision) and ran the IPv6 to_s zero-collapse through regexp; that made parse-v4 (3.33× MRI, 4.46× YJIT), parse-v6 (1.74× / 2.08×), mask (3.59× / 5.52×) and to_s-v6 (1.81× / 1.83×) slower than YJIT. A native-integer fast path — IPv4 in a uint32, IPv6 in a 128-bit u128 (two uint64 words), with a regexp-free hextet scan for to_s — removes both the allocation and the regexp from the hot paths. The construction/format ops collapsed by ~40–200×:

vs YJIT is the go-ruby ns/op divided by the MRI + YJIT ns/op; all six are well under 1.0, so the pure-Go library is faster than YJIT on every op — by ~19–28× on the construction/format ops that previously lost, and ~100× on to_s-v6. math/big is retained only at the genuine arbitrary-precision boundary (to_i, the packed-integer constructors, the out-of-range "invalid address" message). The TruffleRuby include (4.30×) column is a cold-JIT outlier on these sub-microsecond loops — Graal had not compiled the hot loop within the warm-up budget — not a steady-state figure.