go-binsync — patch explorer

A deployed Go binary is updated for real, in front of you. The page fetches the same pointer, the same patch and the same blob a go-binsync agent would, from a machine in the region you pick, and the machine applies the patch with the same decoder a target runs. Nothing here is cached, simulated or pre-recorded.

Release

From region

What happens

The same release, the other ways

Both fetch the real bytes from the same machine, so the time is comparable with step 2 above. They are capped at ten downloads per visitor — the demo pays for the egress.

What every technique costs on this pair

Rows without a star are the bytes this page will actually serve you. Starred rows are measured on the same pair in docs/research/ and are not hosted here — there is no point paying to ship 25 MB of chunk store to make a point that a number makes.

Reading the numbers honestly

The path from your browser to the chosen region is a real one and an uncontrolled one: you reach the nearest edge and the request crosses a backbone from there. That backbone has near-zero loss, so what you see is the cost of distance — round trips and slow start on the big objects — not the collapse of a single TCP stream under packet loss, which is where a small patch wins hardest. Measured under netem at 20 Mbit/s, 200 ms RTT and 1 % loss, the full download of the prometheus release takes about 2.4 minutes and the patch about a second.

Step 3 runs on the machine, not in your browser: the decoder needs about 7.6× the binary in memory, which is 0.7 GB for the 94 MB pair. Shrinking that is the open item that moves the apply into a tab. The machine is a shared 2-vCPU box, so the apply you see is two to four times what the same patch costs on a server with cores to spare — 0.9 s for the prometheus pair.