DEV Community: Efrain Garay

Don't put getaddrinfo on your proxy's hot path

Efrain Garay — Thu, 10 Sep 2026 21:11:48 +0000

I set out to benchmark Pingora 0.9.0 — the Rust proxy library Cloudflare runs at its edge — against nginx, in the environment I actually care about: a small pod with a CPU limit, two vCPUs, everything in containers so no number leans on the host.

I wrote the simplest possible reverse proxy with Pingora, hit it, and got 21k requests/sec against nginx's 126k in the same setup. Six times slower.

That number was a lie, and the fault was mine.

Six times is too much — Cloudflare would not replace nginx with something 6x slower. So I isolated it. Not CPU throttling (nr_throttled was zero). Not thread oversubscription (exactly two workers). Not connection reuse (both held ~130 upstream connections). The clue was latency: 4.78 ms in the container, 0.45 ms on the host with the backend at 127.0.0.1. The only thing that changed was how I named the backend.

My upstream_peer built the destination on every request:

// (&str, u16) → to_socket_addrs() → getaddrinfo, blocking, on the tokio worker
let peer = HttpPeer::new(("backend", 80), false, String::new());

HttpPeer::new over a (&str, u16) calls getaddrinfo synchronously, inside the tokio worker thread. In a container, every request fired a DNS query to Docker's resolver and blocked the thread. On the host, an IP literal is just a parse — no syscall — so it barely showed.

The fix is one line: resolve once at startup, keep the SocketAddr, pass that on the hot path.

let addr = ("backend", 80).to_socket_addrs()?.next().unwrap();
// ...on every request, no lookup:
Ok(Box::new(HttpPeer::new(self.addr, false, String::new())))

Pingora went from 21k to 89k req/s in the same pod. The 6x was a getaddrinfo per request, not the framework.

The lesson isn't about Pingora. A microbenchmark punishes any clumsiness of whoever writes it, and a blocking name resolution hidden on the hot path disguises itself perfectly as "the framework is slow."

With the proxy written properly, the real gap in a 2 vCPU pod is 1.49x — and perf pins it down to the cycle: Pingora runs 1.7x more instructions per request. I also found Pingora's thread default is 1 (a whole idle core if you don't set it), and that in a CPU-limited pod, more threads than cores wrecks the p99 through CFS throttling.

I documented the whole thing — the container setup, the full concurrency matrix with repetitions, the perf/strace profile, the flamegraph, and the thread-throttling numbers — with live diagrams and a reel, here:

👉 The full write-up on efraingaray.com

If you benchmark a Rust proxy in a container: resolve upstreams by IP or once, and set threads equal to your CPU quota. Those two lines matter more than the framework you pick.

pg_anon caught 1 of my 8 PII columns. My schema isn't in English.

Efrain Garay — Sun, 06 Sep 2026 03:20:27 +0000

pg_anon found 1 of the 8 personal-data columns in my PostgreSQL database. The one it caught was email, and only because "email" is spelled the same in Spanish and English.

The other seven — nombre, apellido, telefono, direccion, fecha_nac, tarjeta_ult4 and rut — walked straight through, unmasked.

pg_anon is the open TantorLabs tool that masks personal data in PostgreSQL: it scans the database, flags the sensitive columns, and dumps a masked copy. Like pg_dump, but covering the sensitive parts on the way out. Exactly what you want before handing a colleague a copy of production. So I fed it a Chilean database and watched it miss almost everything — no error, no warning. It finished successfully and handed me a dump with names and national IDs still in cleartext.

What the scan actually does

Two filters, in order. First it reads each column's name against a set of regexes (^email$, ^phone$, ^ssn$…). To the columns left over, it opens the data and tries patterns on the value (an email's @, a card's 16 digits). Whatever no filter catches passes through.

The rules in the demo meta-dict it ships with are written for English schemas. Mine aren't.

1 of 8

Column	Holds	Stock rules
`email`	email	✅
`nombre`	first name	❌
`apellido`	surname	❌
`telefono`	phone	❌
`direccion`	address	❌
`fecha_nac`	birth date	❌
`tarjeta_ult4`	card digits	❌
`rut`	national ID	❌

email got caught by name (it's an English word) and confirmed by its @. Everything else has a Spanish name no stock rule looks for.

The rut is the clearest miss. A RUT looks like 7917183-2: seven or eight digits, a dash, and a mod-11 check digit that can be the letter K. The only national-ID rule pg_anon ships with is ssn. It has no idea what a RUT is — and it won't know a cpf (Brazil), dni (Spain, Argentina), curp (Mexico), nif (Portugal) or aadhaar (India) either. If your schema isn't American, the defaults miss your most sensitive column.

The fix: a few lines of Spanish

You teach it. Column names in your language, plus a content regex for the ID so it's caught even in a column not named rut:

{
  "field": {
    "rules": ["^nombre$", "^apellido$", "^email$", "^telefono$",
              "^rut$", "^direccion$", "^fecha_nac$", "^tarjeta_ult4$"],
  },
  "data_regex": {
    "rules": [
      r"[\w.-]+@[\w-]+\.\w+",   # email
      r"^(\+?56)?9\d{8}$",     # Chilean mobile
      r"^\d{5,8}-[\dkK]$",      # RUT with check digit
    ],
  },
}

With that, recall went from 1 of 8 to 8 of 8, no false positives — it still left the non-personal columns alone. The point isn't "it went up when I wrote the rules" (obviously). It's how cheap the fix was, and that a masking tool ships blind to any schema that isn't English.

I left the full Spanish meta-dict (with the RUT regex) in a public repo so nobody starts from scratch: pg-anon-rules-es.

This is the short version. The full write-up covers what didn't fit: whether foreign keys survive the restore, the trap where a blanket SHA-256 keeps uniqueness but produces "emails" with no @, and how much slower it runs than a plain pg_dump. Numbers, diagrams and a 47-second breakdown: pg_anon found my database's emails, but not the RUT.

What does the national ID look like where you are — and would a stock masking tool catch it? Drop the format (or the regex) in the comments and I'll add it to the repo.

I translated DOOM from C to Rust in 23 seconds, then used AI for what it is good at

Efrain Garay — Fri, 21 Aug 2026 21:58:13 +0000

I needed to move a C program to Rust. My first instinct was the easy one: hand it to a model, chunk by chunk, and review the output.

Then I checked whether a tool already existed. c2rust, from Immunant, does exactly this. On the 73,095 lines of doomgeneric it took 23.2 seconds.

The interesting part is not the speed. It is that the model still ended up doing real work, just nowhere near the translation.

Cost was not the argument, and pretending otherwise would be selling smoke

I measured the token cost of translating DOOM with a model using the o200k_base tokenizer: 550,595 input tokens and 1,896,319 output. That is a few dollars. It is not a reason.

What actually decides is three other things:

Reproducible. Same input, same output file, byte for byte, every run. You can diff it.
Systematic errors. The translation produced four bugs. Two were the same bug in 23 places. One class gets fixed once.
All of them failed loudly. Every one crashed at compile time or on the first frame. A scattered, silent error in one of 143,911 lines costs more to find than the whole translation.

How you prove a translation did not change the program

DOOM ships recorded demos. Every gameplay decision is a fixed-point calculation, so if one of them differs the playback desynchronizes and the tic count stops matching. That is the first gate, and it is free.

The second gate: I hashed every frame the engine hands to the display, in both builds. 11,113 frames, one differed.

I nearly published that one frame as c2rust's single error. The control run is what saved me: I ran the original C binary against itself. It differs from itself too, on the same pixel. Original DOOM reads one pixel of uninitialized memory, and the translation reproduced that faithfully.

If you only ever compare against one run, you will report your own reference's noise as the other side's bug.

The translated Rust is not safe Rust

Measuring lines inside unsafe blocks, the translated zlib puts 47% of the crate in unsafe, against 31% for zlib-rs, a rewrite done by people.

Counting occurrences of the word unsafe gives you the opposite answer, and it is a misleading metric: the translator wraps whole functions in a single block, so it scores better on a count while being worse in reality.

These are not comparable artifacts anyway. zlib-rs is a rewrite, with redesigned structures and the type system doing work. An automatic translation cannot do that. Its goal is to not change the program.

Where the model actually earned its place

Not translating. Generating detail that modulates on top of what the engine already computes.

Every texture goes through an upscaler, then gets stored as a one-channel map whose mean is exactly 128 per texel. The renderer keeps deciding color and lighting; the map only contributes variation within the texel:

color_final = color_doom × detail / 128

Because the mean is anchored at 128, the enhancement provably cannot shift the image. Averaged over any texel, it multiplies by 1.

And that same map is a height map, so its gradient gives per-pixel relief for free, with no extra bytes, baked at pack time.

That constraint, that the engine keeps deciding, is what made the result add instead of ruin.

Both versions are playable in your browser

The 1993 C build and the Rust translation are compiled to WebAssembly and running side by side, plus the enhanced renderer at 640×400 with per-pixel lighting.

The 60-second version of all of this, with the game running behind it:

The full write-up has the four translation bugs, the three portability ones, the memset that silently cleared half the screen after widening a struct field, and how it went from 7215 to 3009 realtics without rewriting the game:

I translated DOOM from C to Rust without writing a line, then used AI for what it is actually good at

Go 1.27's SIMD ties with NumPy until the data fits in cache

Efrain Garay — Thu, 20 Aug 2026 17:02:12 +0000

Go 1.27 shipped a simd package in the standard library. It is experimental and sits behind a flag, and every write-up I found described the API. None of them said when it actually helps.

So I measured it against NumPy on the same task: a speaker-search index, 346 thousand vectors of 192 dimensions, 66 million multiplications per query.

The answer turned out not to be about Go or NumPy at all.

Same code, two verdicts

With a 253 MB corpus, single-threaded:

	median	spread
Go SIMD	9.54 ms	14%
NumPy (OpenBLAS)	9.76 ms	10%

That is a tie, not a win. The 2% gap fits entirely inside the noise.

With 31 MB, which fits in the L3 cache:

	median
NumPy (OpenBLAS)	0.393 ms
Go SIMD	0.943 ms

NumPy is 2.4× faster. Same code, same machine, same afternoon.

Why the reversal

The number that explains it is not in either table. Parallelising across eight physical cores gave 2.9× in Go and 3.0× in NumPy. Pure computation would give close to 8. Both stopping at 3 is the tell: the ceiling is not the code.

At 253 MB nothing fits in any cache, so both programs spend most of their time waiting on memory. When two implementations hit that wall, code quality stops mattering. Twenty lines of a brand-new portable package match assembly that has been hand-tuned per microarchitecture for years.

At 31 MB the data sits in L3, the bottleneck goes back to arithmetic, and OpenBLAS's years of tuning show up immediately.

What decides is not the language. It is whether the data fits in cache.

The 55-second version of all of this, narrated:

The part worth stealing

I nearly published the opposite conclusion, twice.

The first run gave NumPy double Go's speed. OpenBLAS spreads work across every core without announcing it, while my Go program ran on one thread. OMP_NUM_THREADS=1 and OPENBLAS_NUM_THREADS=1 made NumPy three times slower and flipped the result.

The second time I measured a machine with thirteen foreign processes at 100% CPU and did not notice. The same numbers came out ten times worse on the check run.

So the harness pins cores with taskset, interleaves the implementations round by round instead of measuring all of A then all of B, aborts if load exceeds 2.0, and reports median and spread rather than the best time. The best time measures the best case and hides exactly the instability that matters.

Its first version printed 0.000 ms for NumPy. Not a record: perf_counter returns seconds and I was printing milliseconds. A suspicious zero is a units bug before it is a marvel.

What this does not prove

Two home machines, one embedding model, two corpus sizes. My Go code walks vector by vector while OpenBLAS solves the whole matrix-vector product with blocking and unrolling. That is a naive implementation against an expert one, which is exactly what you get picking the package up fresh.

The exact numbers belong to this hardware. The shape of the curve repeated on both machines, with synthetic and real data, and that is the only part I would call general.

The full write-up has the synthetic benchmark across three cache levels, the control that separates data size from data nature, a second machine that chose 4 lanes when it could have used 8, and the raw numbers:

Go 1.27 brings portable SIMD: it ties with NumPy out of cache and loses inside it