Making DNS_Erlang Fast: Binary Tricks for the Beam
Comments on “Making DNS_Erlang Fast: Binary Tricks for the Beam”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
DNSimple rewrote the hot paths of dns_erlang, the Erlang DNS library behind its erldns name server, using only BEAM-level binary techniques, with no NIFs. The changes include one append-only encoder accumulator, decoding that stays in the match context, and 56-bit SWAR guards. On a replay of about 19 million production-shaped queries, CPU per query fell 12% and saturation throughput rose 14%. These figures are self-reported and the intermediate benchmarks are unverified. Some earlier optimizations had no end-to-end effect.
Why it ranked
No. 20 of 62 with a score of 0.65. The panel rated it highest on technical depth (0.95) and new information (0.94), lowest on audience breadth (0.42).
Every answer behind this is in the table under Score.
Score
0.65total under rubric v2.2
- Significance0.54
- Reader interest0.79
- Audience breadth0.42
- Practical relevance0.73
- Substantiated0.90
- Technical depth0.95
- New information0.94
- Counts against: Promotional0.14
- Counts against: Overclaim0.14
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| Significance | 0.61 | 0.30 | 0.70 | 0.54 | 0.40 | +0.24 | +0.129 |
| Reader interest | 0.75 | 0.72 | 0.90 | 0.79 | 0.18 | +0.26 | +0.205 |
| Audience breadth | 0.59 | 0.25 | 0.42 | 0.42 | 0.34 | +0.13 | +0.055 |
| Practical relevance | 0.83 | 0.55 | 0.82 | 0.73 | 0.28 | +0.22 | +0.162 |
| Substantiated | 0.98 | 0.80 | 0.93 | 0.90 | 0.18 | +0.05 | +0.045 |
| Technical depth | 1.00 | 0.90 | 0.96 | 0.95 | 0.10 | +0.05 | +0.048 |
| New information | 0.95 | 0.90 | 0.98 | 0.94 | 0.08 | +0.05 | +0.047 |
| Promotional | 0.10 | 0.20 | 0.12 | 0.14 | 0.10 | −0.19 | −0.027 |
| Overclaim | 0.18 | 0.15 | 0.08 | 0.14 | 0.10 | −0.11 | −0.015 |
| Sum of contributions | +0.649 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.649 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-10-26/20/"><img src="https://rubric.hrih.si/badge/2026-10-26/20.svg" alt="Ranked #20 on Rubric, 26 Oct 2026" width="245" height="28"></a>Claim check
Claim check: 2 no source given · 6 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenNumber
On a production-shaped workload, DNSimple's nameserver now spends 12% less CPU per query and serves 14% more queries per second before saturating, from dns_erlang library changes alone.
The article gives no link or citation for it.
The article says “our nameserver now spends 12% less CPU per query and serves 14% more queries per second before saturating, from library changes alone”
The source says No source to compare with.
Couldn’t checkBenchmark result
On the UDP response path on the M4 Pro, a simple response went from 708 ns to 583 ns and from 1.89 KB to 1.23 KB allocated after the single-accumulator encoder rewrite.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “a simple response went from 708 ns to 583 ns and from 1.89 KB to 1.23 KB allocated”
The source says No passage could be compared.
Source cited by the article: github.com/dnsimple/dns_erlang/pull/139
Couldn’t checkNumber
Building the #dns_message{} record once at the end instead of updating it per section cut 11% of the reductions and 10% of the allocation when decoding a query.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “cut 11% of the reductions and 10% of the allocation for decoding a query”
The source says No passage could be compared.
Source cited by the article: github.com/dnsimple/dns_erlang/pull/135
Couldn’t checkBenchmark result
OTP pull request #10938 applying SWAR to the json module's string scanning shrank the JIT output of the hot loop from about 1,750 lines of assembly to about 100 and improved Jason-derived benchmarks by 3% to 55%.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “The JIT output for the hot loop shrank from about 1,750 lines of assembly to about 100, and 768 jump-table entries disappeared. Benchmarks borrowed from Jason improved by 3% to…”
The source says No passage could be compared.
Source cited by the article: github.com/erlang/otp/pull/10938
No source givenVersion
The SWAR changes to the OTP json, OTP string and Elixir String modules all shipped in OTP 29 and Elixir 1.20.
The article gives no link or citation for it.
The article says “All three shipped in OTP 29 and Elixir 1.20”
The source says No source to compare with.
Couldn’t checkNumber
Elixir's String.length/1 became 2 to 5 times faster on ASCII strings with the SWAR change.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “String.length/1 got 2 to 5 times faster on ASCII strings”
The source says No passage could be compared.
Source cited by the article: github.com/elixir-lang/elixir/pull/15255
Couldn’t checkBenchmark result
Batching suffix inserts into the compression map made encoding a name with 50 one-character labels go from 211 µs to 9.4 µs, and an ordinary 8-label name from 1.51 µs to 0.54 µs.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “For a name with 50 one-character labels, encoding went from 211 µs to 9.4 µs, 22 times faster”
The source says No passage could be compared.
Source cited by the article: github.com/dnsimple/dns_erlang/pull/133
Couldn’t checkNumber
Björn Gustavsson's OTP change replaced the earlier hex encoding dispatch, and the same pull request made binary:decode_hex/1 almost ten times faster.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “The same pull request made binary:decode_hex/1 almost ten times faster”
The source says No passage could be compared.
Source cited by the article: github.com/erlang/otp/pull/6869
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 2 pts, not on front page
Recorded for context only, checked 26 Oct 2026, 07:27 UTC. It played no part in the ranking.