DEV Community: codewitharyan29

Our laptop said 37 MB, the scoreboard said 195: 8 lessons from Speed Demon 2026

codewitharyan29 — Sat, 07 Nov 2026 11:03:02 +0000

Our laptop said 37 MB. The scoreboard said 195 MB. That was the first of eight times in 72 hours that the live board told us we were wrong about our own code, and each time, being wrong taught us more than being right.

It also moved us up. On November 1 our Track C solution sat 43rd of the 91 teams that had scored it, at K 23.9 while the leaders were between 41 and 47. A day later it was K 32.4, and our Track D build had reached #9 of 117 on the board.

This post is about those corrections. Speed Demon 2026 is a 72-hour performance-engineering hackathon run by Hackathon Raptors. Four tracks each hand you a correct but naive Python program, and you make it as fast as you can without changing a byte of its output. Every push is built and run on one fixed machine, and a wrong output hash scores nothing. Our team, Bharat Labs (Aryan Verma and Lakshya Varshney), entered all four tracks. Everything is in the repo: github.com/codewitharyan29/speed-demon-2026.

Wall time on a log scale; the labels show exact times and speed-ups.

Track	Language	Reference	Our best board run	Speed-up
A: Ingest (log to hourly percentiles)	Rust	32.05 s, 228 MB	23.6 ms, 18.4 MB	~1,350x
B: Index (boolean and phrase search)	Rust	56.35 s, 2,200 MB	105.4 ms, 39.7 MB	~535x
C: Join (quoted CSV join)	C++	14.44 s, 367 MB	34.0 ms, 13.6 MB	~425x
D: Traverse (shortest paths)	C++	72.69 s, 893 MB	122.5 ms, 66.1 MB	~593x

Zero external dependencies on all four. These are our best logged board runs; the last section shows where to verify each one.

How scoring works, in one minute

Each track's score is a multiplier:

K = (T_ref/T)^0.5 x (M_ref/M)^0.2 x (S_ref/S)^0.15 x (1/D)^0.15

where T is wall time, M is peak memory, S is lines of source and D is the number of dependencies (the memory and speed bonuses are capped). A 10% improvement in each term moves K by:

10% better in...	K goes up by
time	about 5.4%
memory	about 2.1%
lines of code	about 1.6%

So doubling K takes four times the speed, and a line of code is worth about a third of what a millisecond is. We kept that arithmetic in front of us all weekend, and it explains several decisions below.

How the 72 hours went

We were two people with one board. The board allows one run per team every five minutes, so every experiment had to be worth a push, and we took turns.

Track	Owner	The idea that mattered most
A: Ingest	Aryan	4-byte packed records, and a checked guess that the log is nearly sorted
B: Index	Lakshya	Compiling each boolean query into a 64-bit truth table
C: Join	Aryan	Finding quoted regions with one carry-less multiply, and never unescaping names
D: Traverse	Lakshya	Bidirectional search with both distances in one 32-bit word

The repo has 266 commits: 110 from Lakshya, 104 from Aryan and 52 from Claude Code sessions we ran. 162 of them carry a Co-Authored-By: Claude Sonnet 5.5 trailer, so a large share of the code and measurement scripts was AI-assisted. We set the goals and ran and read every board result. Our last commit, a README edit, landed at 20:28 IST, two minutes before the freeze. Track B's decisive redesign landed at 19:12.

K for every board run we logged. The green line is our best so far, each dip is an experiment we reverted, and the labelled jumps are corrections from this post.

Correction 1: our memory number was a lie

What we believed. Track A's first serious rewrite used 37 MB on our laptops.

What the board showed. 195 MB.

Why. The scoring machine runs transparent huge pages in always mode, and our Docker VM ran madvise. Our arena was one big sparse mapping with a small region per chunk and hour, so every 2 MiB region we touched was silently backed by a full 2 MiB huge page. We proved it by forcing huge pages on locally, and our own build jumped from 25 MB to 197 MB.

The fix was tiny. Track C gave the cleanest version. One line, prctl(PR_SET_THP_DISABLE), took the same code from 37.5 MB to 16.2 MB, and K from 18.9 to 22.4. In Track A, MADV_NOHUGEPAGE on the arena, plus a layout change, took 195 MB down to 30 MB.

What generalizes. A benchmark number measures a machine plus a kernel configuration. Match the scoring machine's settings before you trust a memory figure.

Correction 2: local numbers don't transfer, in either direction

What we believed. For Track A's 239 MB input, mmap must beat reading: no copies, no buffers.

What the board showed. The mmap build was 14% slower (29.8 ms against 26.2 ms). Page-faulting 239 MB costs real time, and so does tearing the mapping down, which we measured at about 24 ms in an early build. Reading 32 KB blocks with pread keeps data in cache and avoids both.

The same pattern kept appearing, and it cut both ways:

Local wins that vanished. One reader thread per parser was about 19% slower on the board (30.4 against 25.7 ms). Writing Track A's output with fadvise cut peak memory locally from 17.4 MB to 9.4 MB, and the board's M did not move (19.53 against 19.49 MB). In Track C, an "instruction diet" cut instructions by 14% and ran 2.1 ms slower. We never found the cause, so the log says "cause not found".
Peak memory is a maximum, not a sum. In Track D, query-phase memory fell from 74 MB to 36 MB locally, and the board's M did not budge, because the peak sat in the graph build. Reading memory.current at each barrier showed it: the five build arrays together.
A small local gain that was huge on the board. In Track B, moving serial work into parallel pieces saved about 5 ms on our laptops and 35 ms on the board (0.242 to 0.207 s). The scoring box has turbo off and runs a core at about 2.5 GHz against our laptops' ~4.8 GHz, so every serial millisecond costs it far more.

What generalizes. Fewer instructions, fewer copies and tidier code are hypotheses about time. Only the scoring machine decides, and it can disagree in either direction.

Correction 3: the log was "nearly sorted", and the spec didn't promise it

What we believed. Track A's log is sorted by time, so we can finish an hour early and free its memory.

What we found. We measured the data: 13% of lines sit in an hour behind the newest one, 26,000 lines have an earlier timestamp than their predecessor, and the largest lag is 70 minutes. That is nearly sorted. But the spec says the log is not sorted, with no bound on how far a line can be out of order.

What we did. We turned the observation into a guess that is checked. A worker summarises an hour as soon as the chunks still to come shouldn't contain it, and every chunk verifies that it never sees an hour already summarised. If one does, the program discards the speculative result and re-runs the whole file in a safe pass. We tested both paths on shuffled and reversed inputs and on 16 adversarial datasets.

Tracks C and D follow the same rule. Track C assumes a newline inside a quoted field is never followed by a digit or a BOM, verifies every chunk boundary, and re-parses unchunked if one fails. Track D answers over 99.98% of queries with a 16-bit bucket queue and escalates the rest to an exact 64-bit bidirectional Dijkstra.

What generalizes. Measure the data, but only rely on what the spec guarantees. For everything else, write the check and the fallback.

Correction 4: the profiler said 270, we had assumed 40

What we believed. Track C's parser finds which commas and newlines sit inside quotes with one carry-less multiply (PCLMULQDQ) per 64 bytes: the running parity of the quote bits is the "inside a quote" mask, and a doubled quote flips it twice. We assumed the rest of the record work would cost about 40 instructions per record. A cachegrind run on the full file said 270.

Why. Names containing a doubled quote (12.6% of all names) each ran a malloc plus a byte loop to unescape. A branch on the quote count was badly mispredicted, and Vec::push capacity checks sat in the hot loop.

The fix was a different question. We stopped asking how to unescape faster and asked what the output needs. It needs equality of names, and a quoted name with doubled quotes maps one-to-one onto the real string. So two names are equal exactly when their raw bytes are equal, and we never unescape anything.

What generalizes. Before optimising a step, ask whether its result is ever used. Often only a property of it is.

Correction 5: the spec was a data structure in disguise

What we believed. Track B, boolean and phrase search over a 254 MB corpus, needs an inverted index. Ours used 328 MB and scored K 10.3.

What changed. Two spec facts we had read but not used. The memory multiplier maxes out at 44 MB, so a global posting list could never fit. We switched to indexing and answering one chunk at a time on 12 workers, and memory fell from 171 MB to 62 MB in one step.

And boolean queries have at most 6 distinct terms. Six terms means 2^6 = 64 combinations of "present or absent", exactly the number of bits in a u64. Each query compiles into a 64-bit truth table, and answering a document is one expression:

hit = (table >> mask) & 1

where mask is six presence bits gathered from a small L1-resident bitset in one AVX2 instruction. No posting lists, no intersections. Time fell from 163 ms to 105 ms, and the source from 1,285 lines to 961.

What generalizes. Re-read the spec for suspiciously small numbers. A bound is often a license to replace a general structure with a specialised one.

Correction 6: the idea we rejected twice worked the third time

What we believed. Bidirectional search wasn't worth it for Track D. Lakshya had tried it twice in the Rust version and rejected it both times.

What changed. In the C++ rewrite he looked at why it had failed. Both attempts put a reverse graph of 8-byte edges next to a 40 MB forward graph, with separate distance arrays. The failures were verdicts on two implementations, not on the idea. The third version used a compact reverse graph, built after the build arrays were released so the memory peak did not move, and stored forward and backward distances in one 32-bit word, so checking whether the two searches have met costs no extra cache miss.

Query time fell from 95.6 ms to 39.5 ms (-59%), and the whole run by 27% locally. The board confirmed it in full: 0.2418 s to 0.1783 s, K 20.9 to 24.0. One bug on the way mixed u32 and int, so unreachable queries printed 4294967295 instead of -1. Exactness checks against the reference are what make a bug like that visible.

What generalizes. Write down why an idea failed, not just that it failed. When the surrounding design changes, the reason may no longer apply.

Correction 7: lines are cheap, but only if they are free

What we believed. Source size is part of the score, so shorter is always better.

What the formula says. Lines are worth about a third of time (see the table above), so a line-saving change has to cost almost no speed. Two experiments showed it.

In Track C, our C++ rewrite kept the Rust version's architecture and shrank it from 656 to 434 lines at about the same speed. The formula predicted K would rise from 29.63 to about 31.5, and the board measured 31.51. In Track A, a from-scratch minimum-lines rewrite (304 lines instead of about 500) earned x1.076 in K for the lines but cost x0.77 for the time, so K fell from 41.9 to 32.8.

What generalizes. Do the arithmetic of the scoring function before you pick a direction. Short code is a bonus on top of speed, never a substitute for it.

Correction 8: we trusted a single run

What we believed. If a change makes the board time go down, it worked.

What the board showed. The same Track C source, run three times, gave 52.6, 52.9 and 55.8 ms. Board noise is about 6%, so any "win" smaller than that was a coin flip. What we did about it:

Interleaved board comparisons. 34 of our commits push a candidate and a control build of the last known-good code alternately, for example a1, read2, parse2, a1, pct2, fmt2, a1. If the machine drifts during the session, it drifts under both. In Track C, a candidate called cx22 (clean under three sanitizers) measured slower than cx19b this way, so we restored cx19b. The builds we left in place at freeze for Tracks A and C, called LF3 and cx40c, came out of these comparisons.
Diagnostic builds. 11 more commits deliberately skip or repeat one stage just to time it. A build that read every block and did nothing else ran in 8.4 ms in Track A, so we knew the floor before optimising.
Source hashes in commit messages. In the very last comparison push, a runner argument error copied a Rust file over our C++ source. Each commit message records the source's sha256 prefix, so the restore commit could name the exact file it put back, and anyone can check it.
Labelled claims. Our competitor notes tag each statement VERIFIED or HYPOTHESIS, and they say plainly that we looked at nobody's code.

What generalizes. Measure your noise first. Then compare against a control in the same window, not against yesterday's number.

Eight lessons, one line each

Match the scoring machine's kernel settings before trusting a memory number.
Treat every local speed-up as a hypothesis; the scoring machine can disagree in either direction.
Measure the data, but rely only on what the spec guarantees, and keep a checked fallback for the rest.
Before optimising a step, ask whether its result is even needed.
Read the spec's small numbers as hints for specialised data structures.
Record why an idea failed, so you know when to try it again.
Do the scoring arithmetic first: time is worth about three times as much as lines.
Know your noise floor, and compare against a control in the same window.

If we did it again, we would do 1 and 8 on day one and pick each track's architecture within the first six hours. Our biggest gains came from design changes, not micro-tuning.

We accepted one risk knowingly. Track A's endpoint dictionary trusts a 64-bit hash and never compares key bytes, with a collision chance of about 1 in 10^13 across at most 1,842 endpoints. It measured about 7 ms faster locally. A byte-verified version exists and costs a few percent, and the README names both.

If you remember one thing from this post: every belief about performance is a hypothesis until the machine that scores you agrees. We were wrong eight times, and the leaderboard is where we found out.

The final run

After the freeze, Hackathon Raptors re-runs the top teams on a hidden holdout dataset. Our results are on the Showtime page.

Check our numbers

Every figure comes from the PERF.md logs and the commit history in the repo.

Track	Logs	Board run / commit
A	PERF.md, README	`run-d310f2ad455b` (commit `66693b1`)
B	PERF.md, README	`run-f7d2d327f20c` (commit `4a0b9ec`)
C	PERF.md, README	`run-d8a78803f209` (commit `9bfa8af`)
D	PERF.md, README	commit `18c1dcf`

The results table lists our best logged board runs. The builds at freeze for Tracks A and C (LF3 and cx40c) were chosen by interleaved board comparisons whose numbers we did not copy into PERF.md, so check the live board for those. The 43rd-of-91 figure is from our docs/COMPETITORS.md snapshot of the public board feed (121 teams, 91 with a scored Track C run, generated 2026-11-01 01:57 UTC). The #9-of-117 ranking for Track D is from our log of the step-35 board result. Local timings came from a Windows Docker VM and only ranked ideas against each other, and board numbers carry roughly 6% noise.

Thank you to Hackathon Raptors for a brutal, fun and educational 72 hours. Team Bharat Labs: Aryan Verma and Lakshya Varshney. Code and logs: github.com/codewitharyan29/speed-demon-2026.

Same score, 23 places apart: the normalization maths behind a hackathon judging platform

codewitharyan29 — Fri, 02 Oct 2026 07:11:31 +0000

Two projects in the official DOGFOOD data set both had a raw average score of 3.44, from three judges each.

After I normalized the scores, one finished #37. The other finished #14.

Same number. 23 places apart. This is the story of why, and of the other technical problems I hit while building Verdict, a platform that runs a hackathon end to end: events, teams, deadline-enforced submissions, rubric judging, public voting, certificates, webhooks and an embeddable gallery. It was built for the DOGFOOD hackathon by @partnerships_raptors.

Stack: FastAPI, SQLAlchemy 2.0 async, PostgreSQL, Redis, Next.js.
Repo: https://github.com/Lakshya-Varshney/Verdict
Demo_Video: https://youtu.be/bmdsrYy_dy4

1. The problem: a raw average cannot tell who was asked

The obvious way to rank projects is to average judge scores. It silently assumes every judge uses the scale the same way.

They do not. On the official data (40 projects, 30 judges, 126 review rows), judges with at least 5 reviews had personal averages from 3.11 to 4.22, with the same spread (standard deviation 0.81 for both). That is a full point of pure leniency.

Now look at the two projects:

Project	Raw mean (rank)	Its reviewers' own average	Normalized rank
Flat Meadow	3.44 (#24)	3.97 (generous panel: 4.22, 3.61, 4.08)	#37
Glass Signal	3.44 (#26)	3.48 (close to the pooled mean 3.57)	#14

Flat Meadow got a below-par verdict from each of its reviewers. Glass Signal got a normal one from each of its reviewers. The raw average sees two identical numbers.

2. The fix: per-judge z-scores

For each judge, compute their mean and standard deviation over everything they scored, then convert each score into "how far above or below this judge's own usual":

z(judge, project) = (score - judge_mean) / judge_stddev
normalized(project) = mean of z over the judges who reviewed it

Why z-scores and not min-max or rank averaging? They correct both leniency (the mean) and spread (the standard deviation), and they stay well-defined when projects have different numbers of reviews. Two reviews on one project and five on another is fine, because each project is just the mean over whoever reviewed it.

Result on the real data: 38 of 40 projects change rank, Spearman correlation 0.864 against the raw ranking. I also recomputed everything independently with plain statistics and no application code, and the two agree to floating-point precision.

3. The edge case that decides whether the maths is correct

A z-score divides by the judge's standard deviation. What if a judge gave 4/4/4 on every project? Or reviewed only one project? Then the standard deviation is zero and there is nothing to divide by.

The tempting shortcut is to use that judge's raw score. I rejected it, because it mixes two scales. Raw scores sit around 3.0. Z-scores sit around 0. If you average them together, every project a flat judge touched jumps by roughly that judge's raw score, and the judge with no opinion ends up as the loudest voice in the ranking.

The design that works: standardize the flat judge's raw score against the pooled mean and standard deviation of every score in the event.

if not flat:
    z = (score - mu) / sigma                 # judge's own scale
elif pooled_sd > 1e-12:
    z = (score - pooled_mu) / pooled_sd      # same scale as everyone else
else:
    z = 0.0

The flat judge still contributes a real signal (higher raw score means higher z), it lands on the same scale as everyone else, and it is never silently trusted: they appear in a zero_variance_judges list and in the audit log. The results payload also separates "identical scores everywhere" from "only one review", so the UI never mislabels a judge who simply had too little data. There is a regression test for exactly this: test_zero_variance_judge_does_not_swamp_z_scores.

On the official data, four judges take this path.

4. Real data fights back: the duplicate project row

The official fixtures.json has 41 project rows for 40 teams. prj_41 repeats prj_07: same team, same title ("Dry Harbour"), same repo, different id. Deduplicating by id would never catch it, so I merge by team plus title.

The interesting part is the consequence. Three judges had scored both ids, so their criterion rows collided after the merge: 9 rows, taking 378 score rows down to 369. One of those judges had scored the original at 2.33 and the duplicate at 3.67. Under the documented rule (the later review wins), all three of her remaining projects score 3.67, and she correctly lands in the zero-variance path from section 3.

Data cleaning is not neutral. It changes the maths downstream. So I wrote the rule down (later review wins, averaging is the alternative) and surfaced every flagged judge in the results payload.

5. Role isolation, tested by attacking the running system

Reading the code tells you what you intended. Probing the live API tells you what you built. I ran adversarial probes against the running system and found 12 real problems, each now covered by a regression test. The ones that taught me the most:

An organizer could grant themselves admin. Every permission check accepts admin from any event, so one self-grant meant site-wide control. Only an admin can grant admin now.
Any organizer could read every other event's audit log. 98 of the first 100 rows returned belonged to other events. Audit access is scoped to the caller's own events.
Judges could change scores after results were published. The judging window was enforced in the UI, not the API. A UI button is not an access control.
The vote count was hidden in one field and leaked in another. While voting was open count was null, but vote_count still carried the real number.
alice+1@gmail.com counted as a new voter. Email voting now uses a canonical mailbox: lowercase, drop the +tag, ignore Gmail dots.

Roles are read from the database on every request and scoped per event, so cross-event isolation is structural rather than a convention.

6. A 13 second gallery, and `lazy="raise"`

With the real 40-project data the gallery took 13 s and /roles took 18 s, because SQLAlchemy was eager-loading every relationship.

I set lazy="raise" on every relationship. Any accidental lazy load now throws instead of quietly running extra queries, so every query has to be written explicitly. It forces more typing and gives predictable performance. test_real_scale_endpoints_stay_fast keeps it that way.

7. An audit log you can verify, not just trust

An append-only audit log is normally append-only by convention. Anyone with database access can still edit history.

In Verdict, every audit row contains the hash of the previous row. GET /admin/audit/verify and an offline script both detect tampering. To keep the chain linear, appends take a Postgres advisory lock (pg_advisory_xact_lock), so two concurrent transactions can never read the same tip hash and fork the history.

The same principle runs through the certificates: Ed25519 signatures instead of HMAC, so anyone can verify a certificate offline with only a public key, with no shared secret. Webhooks use a transactional outbox, so events cannot be lost or invented, and no message broker is needed to run offline.

8. The scope decision: normalized absolute scores

Judging can be built two ways: judges score each project against a rubric, or judges compare two projects at a time (pairwise, Bradley-Terry style). I shipped normalized absolute scoring.

It works directly with the weighted rubric, the result is recomputed from raw scores on demand (never trusted from storage), and I could check it independently against the real data. That made the correctness work possible: the normalization proof, the role-isolation tests and the verifiable audit trail.

What I would carry into the next build

Test the maths on messy real data, not a clean example. My clean example proved the idea. The duplicate row and the flat judges decided the actual design.
Attack the running system early. Role-isolation bugs hide in code that reads correctly.
Make failures loud. lazy="raise" and server-side checks turn "slow and silently wrong" into "fails immediately".

The full normalization proof, the threat model and all the tests are in the repo: https://github.com/Lakshya-Varshney/Verdict

Built for DOGFOOD. Tagging @partnerships_raptors for the Write Up Quest.

Killed My Own Process 300 Times to Prove ChronoVault Doesn't Lie About Durability

codewitharyan29 — Thu, 03 Sep 2026 15:27:27 +0000

TL;DR: I built ChronoVault v2 for Hackathon Raptors' Zero Dependency Hackathon (Track D — Data & Storage) — a content-addressable snapshot and recovery engine, zero runtime dependencies, backed by a hand-rolled pack-file format. A comment saying "this is atomic" is worth nothing to a judge, so instead of asserting crash-safety, I hard-killed my own writer process mid-write, over and over, and made the vault prove it survived. This is that story, plus a benchmark number I didn't want to publish and three Windows bugs that only showed up on real hardware.

279 tests. 20 CLI commands. 0 runtime dependencies. judge_mode.py VERIFIED on Python 3.11 and 3.14.

Proving crash-safety instead of asserting it

Anyone can write "atomic writes, crash-safe" in a README. It costs nothing and proves nothing. So recover-check is tested against a real SIGKILL, not a simulated one: a writer subprocess runs a snapshot, gets hard-killed at a randomized point mid-write, and the vault is reopened cold — no manual repair step allowed.

The test checks three things, not one:

Every snapshot acknowledged before the kill is intact.
The in-flight snapshot at the moment of the kill is either cleanly absent or a discarded partial write — never garbage returned from a read.
The vault is immediately usable afterward, with no repair command required.

This is also where the pack-quarantine logic earned its place instead of being a "nice to have." Early in testing, a kill landing mid-pack-write left a truncated pack that the recovery scan initially tried to read as valid — and returned a wrong length from. Quarantine — isolate anything that fails its checksum before it ever reaches the index — closed that hole. The fix wasn't "trust the file less," it was "never let an unverified pack answer a read at all."

Run it enough times and the interesting failures stop being about the crash itself and start being about the code paths a crash exposes that a clean shutdown never does. That's the actual value of hard-killing your own process 300 times instead of once: the first ten runs prove the happy path works, and the next 290 are what find the pack-quarantine gap.

Architecture at a glance

flowchart TD
    subgraph L1["CLI"]
        CLI["cli.py — 20 subcommands"]
    end

    subgraph L2["Core Engine"]
        Snap["snapshot.py<br/>atomic rename + fsync"]
        CAS["Content-Addressed Store<br/>hashlib SHA-256, pack files"]
        Idx["path_history.py<br/>rename-aware lineage"]
        Rec["recover.py<br/>recover-check, SIGKILL-tested replay"]
    end

    subgraph L3["Persistence"]
        Pack[("Pack files on disk")]
        Quar["Pack quarantine<br/>corrupt/truncated packs isolated"]
    end

    CLI --> Snap
    CLI --> CAS
    CLI --> Idx
    CLI --> Rec
    Snap --> CAS
    Snap --> Idx
    CAS --> Pack
    Idx --> Pack
    Rec -.->|verified via SIGKILL injection| Snap
    Rec --> Pack
    Pack --> Quar

    style L3 fill:#2d2d2d,stroke:#f5a623,stroke-width:2px,color:#fff
    style Rec fill:#2d2d2d,stroke:#f5a623,stroke-width:2px,color:#fff

The shape that matters is where recovery sits: it reads pack files directly, never through the CLI or the snapshot writer, the same way a verify-style tool deliberately bypasses the normal open path. That's deliberate — if the write path itself is what crashed, recovery can't depend on any code the crash might have left half-updated.

The number I didn't want to publish

Every other number in this post makes ChronoVault look good. This one doesn't.

I benchmarked vault snapshot against diskcache — the closest real-world comparison for local content-addressed storage:

Metric	ChronoVault	diskcache
Write throughput	baseline	9–13x faster
On-disk size, repeated / near-duplicate snapshots	5–47x smaller	baseline

Why it loses on writes: every vault snapshot call pays for a full content hash of each file plus a pack-index lookup before a single byte is committed, because deduplication has to happen before the write, not after. diskcache skips that entirely. That's the whole trade in one sentence: I pay a hashing-and-lookup tax on every write so a hundred near-identical snapshots don't cost a hundred times the disk.

If your workload is write-latency-bound, diskcache is the right tool and I'm not pretending otherwise. ChronoVault wins when the workload is storage-bound — long retention windows, many near-duplicate snapshots, disk-constrained environments. A real loser column next to a real winner column, not a benchmark that only shows its best number.

Where the standard library actually made me suffer

Three places, all invisible until I tested on real Windows hardware instead of assuming POSIX behavior generalizes.

multiprocessing's spawn context raised a KeyboardInterrupt that wasn't one. Worker processes died mid-operation with nobody near Ctrl+C. Windows' spawn-based multiprocessing ties process teardown to _winapi.WaitForSingleObject, which can surface as a spurious interrupt with no signal ever sent — a path fork-based Unix multiprocessing never touches. I misdiagnosed this three separate times as my own bug before proving otherwise, using a detached Start-Job test that ran the worker fully isolated from the parent's console.

WinError 32 — Windows refusing to delete a file it considers still open. POSIX lets you unlink() an open file; the inode survives until the last handle closes. Windows refuses the delete outright. Handling it meant retrying past the handle-release window instead of importing psutil to hide it.

A join-before-drain ordering bug deadlocked the IPC queue. worker.join() was called before the result queue was fully drained. If the OS-level pipe buffer filled before the parent drained it, the child blocked on a full pipe and the parent blocked on join() — a deadlock that only appears under load. Fixed by draining before joining.

None of these are exotic. They're the specific price of touching multiprocessing and cross-process queues without a battle-tested wrapper library between you and the OS.

The edge case that ate an afternoon

Rename-aware file lineage in the path-history index. The question sounds simple — "was this file renamed, or deleted and recreated?" — until content, path, and inode can each change independently, sometimes in the same tick, with zero heuristics borrowed from someone else's diffing library to lean on.

The ambiguous case that actually happened: a file renamed and edited in the same snapshot cycle. "Renamed A→B, then edited" and "A deleted, unrelated B created" are both defensible reads of the same delta, and guessing wrong either invents a false history or silently drops a real one.

I didn't solve it by getting cleverer. I wrote down, explicitly, which cases the lineage tracker resolves correctly, and which ones it honestly doesn't try to disambiguate. A documented limitation beats a confident guess that's wrong on the exact case a judge tests.

What I'd do differently

The Windows CI matrix went in after most of the Windows-specific bugs had already been found manually, one laptop test at a time. Every area I later ran through real Windows hardware for the first time produced at least one genuine finding. If Ubuntu + Windows CI had existed from the start, at least two of those bugs would have surfaced in an automated run instead of on my own machine, days closer to the deadline than I'd have liked.

Where it landed

279 tests passing on Python 3.11 and 3.14, judge_mode.py VERIFIED
20 CLI commands, zero third-party runtime dependencies
Crash-safety proven, not asserted — recover-check verified against real SIGKILL injection, with pack quarantine closing the gap testing found
CI green across Python 3.10–3.14 × Ubuntu + Windows
STDLIB.md documents 14 real substitutions, each cross-referenced to the file that uses it
All four bonus categories claimed (+16) — Single File, Reproducible Build, Package Killer re-earned via the diskcache numbers above, STDLIB Log

python judge_mode.py

runs the full verification — test suite, single-file hash check, isolated-mode dependency audit, and the content-addressing proof's 8 invariants — as one command, so a judge doesn't have to trust this post; they can re-derive it.

Closing thought

Anyone with an AI coding agent can produce a CLI that hashes files and calls it content-addressed storage. The hard part was building enough ways to catch myself being wrong — a crash-safety claim verified with a real SIGKILL instead of a comment asserting atomicity, a benchmark table honest enough to put a 9–13x loss next to a 5–47x win, and a judge_mode.py that re-derives every claim in this post instead of asking a judge to trust it. The vault is the artifact. The willingness to kill it 300 times and publish what survived is the actual submission.

Repo: github.com/codewitharyan29/ChronoVault-v2
Track: D — Data & Storage

Built for Zero Dependency 2026, run by @partnerships_raptors.

ZeroDependencyHack #Python #OpenSource #DeveloperTools #CLI

PythonStandardLibrary #BuildInPublic

Porting natsort to Rust taught me that "it compiles" is the easy 5%

codewitharyan29 — Thu, 06 Aug 2026 14:44:40 +0000

TL;DR: I ported Python's natsort library to Rust for Port Mortem 2026.

Writing the sorting algorithm turned out to be the easy part.

The difficult part was proving the Rust implementation behaved identically to the original Python library across thousands of edge cases without quietly changing behavior.

That meant treating verification as the real project.

Why I chose natsort

Most demo ports are calculators, parsers, or utilities with a handful of tests.

I wanted something that would actually stress the verification process.

natsort sorts strings the way humans expect:

file2
file10
file20

instead of lexicographic order.

That sounds simple until you discover it supports:

seven algorithm variants
signed and floating-point numbers
scientific notation
full Unicode numeric characters
locale-aware behavior
Roman numerals
fractions
a real upstream test suite covering years of edge cases

A port that looks correct on five examples proves almost nothing.

A port that survives the library's own test suite, differential fuzzing, CLI comparisons, property testing, and mutation testing starts becoming evidence.

The architecture

The verification pipeline ended up looking like this:

             Python Test Suite
                    │
                    ▼
          Thin Python Adapter
                    │
                    ▼
             Compiled Rust Binary
                    │
                    ▼
          Rust natsort Implementation
                    │
                    ▼
 Compare:
 • stdout
 • stderr
 • exit codes
 • ordering
 • fuzz results
 • properties

The adapter intentionally contains almost no logic.

Its only job is forwarding Python test inputs to the Rust implementation.

That design choice turned out to matter more than I expected.

What broke (and why those bugs mattered)

1. Differential fuzzing found a bug in the original library

Differential fuzzing generates thousands of random inputs and compares both implementations.

Most mismatches were my mistakes.

One wasn't.

>>> natsorted(["1e400", "1e500"], alg=ns.REAL)
['1e400', '1e500']

>>> natsorted(["1e500", "1e400"], alg=ns.REAL)
['1e500', '1e400']

Both calls succeed.

Both disagree.

The reason is surprisingly simple.

Both values overflow to floating-point infinity.

Since both become inf, the comparison reports them equal, and Python's stable sort simply preserves whichever order the inputs arrived in.

Rust's f64 behaves the same way.

That means the correct port is not one that "fixes" the behavior.

The correct port reproduces it.

I reported the issue upstream:

natsort#192

Finding a real bug in a mature library simply by holding another implementation beside it was one of the most satisfying moments of the project.

2. My adapter was lying to me

I assumed the adapter was a thin wrapper.

It wasn't.

One function calculated the correct Rust-backed answer...

...and then ignored it.

Instead it silently fell back to a handwritten Python implementation that didn't understand signed numbers or Unicode.

index_natsorted(["-5", "-1", "3"], alg=ns.REAL)

returned:
[2, 1, 0]

correct:
[0, 1, 2]

Differential testing doesn't automatically catch bugs in the adapter.

You have to verify the adapter itself.

That lesson probably saved me more time than any optimization.

3. Windows disagreed with Linux

Everything looked perfect.

Until I ran it on Windows.

Five bugs immediately appeared.

executable needed .exe
python3 didn't exist (py does)
subprocess output defaulted to CP-1252 instead of UTF-8
file reads had the same encoding problem
Unix-only resource crashed benchmarks entirely

None of those appeared on Linux.

None appeared in my development environment.

Every one appeared on a real Windows machine.

"Works on my machine" turned out to be the weakest verification strategy of all.

4. GitHub Actions lied with a green checkmark

The deployment workflow looked successful.

The live website returned 404.

The culprit?

A multi-line shell block:

curl ... | sh
build
deploy

The installation silently failed.

The following commands still exited successfully.

GitHub reported the entire step as green.

The fix wasn't clever.

It was boring.

I switched to:

cargo install wasm-pack

and added a deployment check that refuses to publish unless the expected build artifacts actually exist.

A green checkmark only matters if it's checking the thing you care about.

How I proved behavioral equivalence

The implementation wasn't the deliverable.

Evidence was.

I ended up with six independent layers of verification.

1. Upstream tests

Run the original natsort test suite without modifying it.

Tests excluded only when Rust genuinely cannot reproduce Python-specific behavior, and every exclusion is documented.

2. Differential fuzzing

27,000 seeded comparisons across all algorithm variants.

Same inputs.

Same outputs.

Reproducible failures.

3. CLI differential testing

2,800 CLI invocations comparing:

stdout
stderr
exit codes

Matching output alone isn't enough.

Programs communicate failure through exit codes too.

4. Property testing

Randomized verification of:

idempotence
antisymmetry
transitivity

These find classes of bugs that handwritten examples never will.

5. Mutation testing

I deliberately broke my implementation.

reversed comparisons
removed signs
altered parsing logic

If the verification pipeline couldn't detect injected bugs, it wasn't trustworthy.

Every injected mutation was caught.

6. Honest benchmarking

Instead of publishing a single "10× faster" headline, I reported:

mean
median
p95
p99
peak memory

The real result was 6–8× faster, depending on workload.

Honest numbers build more confidence than inflated ones.

The decision I'd take back

I spent a huge amount of time chasing perfect Unicode parity.

It was technically rewarding.

It pushed differential matching from roughly 43% to 100% across the full Unicode character set.

I'm proud of that work.

But I crossed the point of diminishing returns.

One adapter-level discrepancy survived until the deadline on a single CI runner.

I excluded that specific test rather than claim support I couldn't fully defend.

Looking back, I'd stop polishing Unicode earlier and spend those hours investigating the remaining verification discrepancy instead.

Verification gets exponentially more expensive near the finish line.

Knowing when to stop is part of engineering.

Final numbers

By the end of the project:

Original upstream tests running against Rust
27,000 differential fuzz comparisons
2,800 CLI differential runs
Property testing
Mutation testing
Honest benchmark suite
6–8× speedup
One upstream bug reported
Cross-platform verification on Linux and Windows

Reproduce everything

Everything needed to verify the project is public.

Demo

https://youtu.be/jVz_2AP4U4w

Live WASM demo + verification dashboard

https://codewitharyan29.github.io/Port-Mortem/

Repository

https://github.com/codewitharyan29/Port-Mortem

Upstream issue

https://github.com/SethMMorton/natsort/issues/192

**Hackathon rapters : https://www.raptors.dev/project/code-resurrection-2026-port-mortem

Closing thoughts

Anyone with an AI coding agent can produce something that compiles.

Compilation is the easy part.

The difficult part is proving—without hand-waving—that another implementation behaves the same as the original across thousands of edge cases, different operating systems, different execution paths, and even the original project's own bugs.

By the end of this project, I stopped measuring success by whether the Rust code compiled.

I measured success by how much evidence I had that it behaved like Python.

Built for Port Mortem / Code Resurrection by Hackathon Raptors

#PortMortem2026 #HackathonRaptors #Rust #Python #OpenSource #SystemsProgramming #Testing #Verification #Fuzzing
**