Paid For With Blood — The FFI String Was Not the Bug

DreamScripts' record-reader performance work experimented with using FFI strings in record-loading paths.

The sequence is more useful than the final technique:

• 1db40db tried FFI strings;
• follow-up commits expanded the experiment;
• b575991, 7ef025c, and d171ef4 reverted the group;
• ad910b8 and related commits reapplied it;
• 9f569d0 identified that the FFI strings themselves were not the problem — an incorrect second argument was.

Why this matters

It is easy to tell the wrong story after a failed optimization:

We tried FFI. It broke. FFI is bad.

The history supported a narrower conclusion:

This implementation broke. Revert it. Isolate the failure. The original mechanism may or may not be guilty.

The rule

A failed implementation does not falsify every underlying hypothesis, and a plausible hypothesis does not excuse a broken implementation.

Use small commits, reverts, instrumentation, and reproduction to separate them.

The commit history should preserve the uncertainty while the investigation is active. Do not rewrite the story afterward as though the answer was obvious.

Read the initial record reader and the reapplied implementation alongside the full evolution compare.

Sources: DreamScripts commits 1db40db, b575991, 7ef025c, d171ef4, ad910b8, and 9f569d0.

Provenance chain

Experiment → breakage → revert → investigation → actual cause → reapplication. Read the commits in that order; the point is not that the first optimization was foolish, but that it was reapplied only after the real failure was isolated.