What the Numbers Say

Real nanosecond traces from 11 languages, captured in Docker on identical hardware. Every number on this page comes from instrumented code you can run yourself: github.com/adamzwasserman/honest-code-traces

Correction, 3 and 4 October 2026. The first version of these traces measured the wrong thing. It timed the dishonest path in six pieces and the honest path in four, with two clock reads around each piece, so the dishonest side paid for more clock reads than the honest side before either ran a line of its own code. Three more defects affected the labels and the singleton row. We rewrote all eleven harnesses to time the whole scenario, so both sides pay the cost of the clock once per pass, and on 4 October we rebuilt the dishonest class so its calls must run in order. Every number on this page comes from the rewritten harnesses, and all eleven numbers changed. The corrected ratios came out higher than the old ones. That is not why we changed the method: the old numbers did not measure what we said they did. The old measurements stay in the repository for anyone who wants to compare.

1. The Ranking

We timed one whole order in each language: three items and a coupon, with tax. We wrote it twice. The dishonest version is a class with separate methods, addItem, applyCoupon, calcTotal, calcDiscount and calcTax. They must run in that order, because each reads fields the others wrote, and the class looks up the coupon and tax tables through singletons. The honest version is two pure functions over plain data: one applies the coupon and one adds the tax. Both return the same total, 87.45 for the sample order. The dishonest class also stamps itself with the time after every item and coupon. We measured the stamps apart and left them out of the dishonest figure, so the dishonest figure pays for no clock reads. Each figure is a median on one rented eight-core server, inside one Docker image.

We checked every language with a benchmarking tool: Google Benchmark for C++, Go’s own testing package, mitata for TypeScript, JMH for Java and Kotlin, BenchmarkDotNet for C#, the Benchmark package for Swift, benchmark_harness for Dart, pyperf for Python, benchmark-ips for Ruby and PHPBench for PHP. We also ran our own hand-written loop in every language, which times 1,000 passes between two clock reads. Where the tool and the loop disagreed, we kept the pair with the smaller ratio. That was the loop for TypeScript and PHP, and a tool for the rest.

Language	Dishonest	Honest	Ratio
Go	311 ns	42.8 ns	7.27x
C++	104 ns	19.5 ns	5.35x
Swift	282 ns	114 ns	2.47x
Python	1,519 ns	693 ns	2.19x
Ruby	2,248 ns	1,137 ns	1.98x
C#	88.2 ns	49.8 ns	1.77x
PHP	964 ns	600 ns	1.61x
Kotlin	42 ns	30.5 ns	1.38x
TypeScript	93 ns	69.5 ns	1.34x
Dart (precompiled)	140 ns	120 ns	1.16x
Java	38.1 ns	36.2 ns	1.05x
Dart	75.4 ns	72.2 ns	1.04x

The chart is ordered by honest speed, fastest first, and the table by ratio, largest first. The ratio column shows how many times slower the dishonest version is. Honest code was never slower than dishonest code in any language we tested. It was faster by a real margin in 10 of 12, from 1.2x (Dart (precompiled)) to 7.3x (Go). In Java and Dart the two are the same within measurement error.

2. The Surprise

Does honest code in a "slower" language beat dishonest code in a "faster" one? Here it does.

3. Why the Gap Exists

The dishonest path in the demo runs 15 steps: 5 method calls, 4 field writes, 1 computation, 2 singleton lookups, 1 table lookup and 2 timestamp writes. The honest path runs 9: 2 function calls, 2 argument passes, 3 pure computations and 2 return values. Same business logic, same result. The dishonest class needs its methods called in the right order. The honest functions do not, because each takes what it needs as arguments.

We wrote the dishonest code with care to represent the skill and training of the average programmer, not those of the best programmer. For honest code that distinction matters little, because the honest shape leaves much less room for variation. Two pure functions over plain data look much the same no matter who writes them. The one skill that does set programmers apart in Honest Code is decomposition: splitting a complex code path into functions that each do one thing. That skill needs a code path complex enough to split, and an example short enough to fit on a page does not have one.

The demo on the home page is a reconstruction of that structure. It scales the steps so each side adds up to the measured total, and the proportions between steps follow an earlier per-step timing, so read the totals as the measurement and the steps as the shape.

4. Beyond Method Dispatch

The numbers above measure one anti-pattern: mutable classes with singleton lookups. Dishonest code takes many other forms. Most of them are better described by counting than by timing, so here we count. Each row comes from the demo in the chapter named, and each count is a fact about the code in that demo, not a measurement of how long it runs. The book goes into detail about why each of these is an anti-pattern, in the chapter named in the second column.

Anti-pattern	Chapter	What we count	Dishonest	Honest	Ratio
Try/catch recovery chain	7	address spaces touched	6	2	3.0x
Mock-heavy test	9	lines of test code	46	11	4.2x
Scattered state	5	places the same value lives	6	1	6.0x
Middleware chain	1	stack frames	13	4	3.2x
Object graph	3	heap allocations	6	3	2.0x
ORM + cache miss path	8	steps to answer one request	10	3	3.3x

The pattern holds across every anti-pattern

Method dispatch overhead (Section 1) is not a special case. The same structural tax appears when you scatter state across locations, when you build deep middleware chains, when you chase pointers through object graphs, when you wrap exceptions in recovery ceremony, and when you bury your test logic under mock scaffolding. In every case, the honest alternative has fewer steps, fewer address spaces and fewer indirections. The counts differ by 2.0x to 6.0x, and the direction never changes.