Mel 讓每道指令都對上磁鼓讀取頭——並勝過組譯器

在 Ed Nather 於 1983 年發表的 USENET 文章〈The Story of Mel, a Real Programmer〉中，Mel 是 Royal McBee Computer Corp. 的程式設計師；該公司製造 LGP-30 與較新的 RPC-4000——這些都是廉價的磁鼓記憶體機器。Mel 不認同編譯器（「如果一個程式不能改寫自己的程式碼，那它有什麼用？」），他曾以原始十六進位寫出公司最受歡迎的程式：一款二十一點遊戲，在每場電腦展上都讓 LGP-30 攤位擠滿人，而 IBM 業務員只能站在一旁彼此聊天。

Mel 的技藝在於時序。在磁鼓機器上，唯有每道指令都在前一道指令完成時恰好抵達讀取頭，程式碼才能跑得快。當時已有為此設計的最佳化組譯器，但 Mel 拒絕使用，因為它的配置無法預測，且會迫使他必須另設常數。他熟知每個作業碼的數值，並自行指派磁鼓位址，因此能把任何指令當成數值常數——取用先前的一道加法指令，再拿它來做乘法。

他先寫最內層迴圈的內容，讓它們佔到最佳的磁鼓位置，並在剛過讀取頭處刻意加入延遲，使這些延遲耗掉整整一圈——也就是「最 pessimum」。Nather 把 Mel 手工最佳化的程式與同一份程式碼經最佳化組譯器處理後的結果相比：「Mel 的總是跑得更快。」文章最後以一項變更請求作結：業務部門希望加一個變換開關，讓顧客在二十一點中能贏。

Mel 起初對這種不誠實的做法感到抗拒，後來照辦了——但他把測試寫反了，於是那個開關反而讓機器作弊，每次都贏。他宣稱自己的潛意識具有無法控制的道德感，並拒絕修正；Nather 的文章則把這段插曲變成電腦界轉載次數最多的民間傳說之一。

先寫最內層迴圈，並安排每道指令準時對上讀取頭——利用作業碼的數值作為常數，以實現自我修改的程式碼。

磁鼓延遲使得指令配置成為快速程式碼與龜速程式碼之間的差別。

最佳化組譯器雖最佳化了配置，卻破壞了程式設計師對配置的控制。

先寫最內層迴圈，讓最熱的程式碼在其他一切之前先佔到最佳位址。

透過作業碼即常數的算術來自我修改程式碼，完全免除了另設常數的需要。

真正的最佳化利用的是機器的物理特性，而非工具鏈：熟知每個作業碼數值的人，能把常數變成程式碼，並把時序變成設計材料。

這篇文章成為電腦界轉載次數最多的民間傳說之一，而「不太最佳」一詞也透過 Mel 所創的「最 pessimum」進入程式設計師的詞彙；RPC-4000 與 Royal McBee 本身早已消失，主要透過這個故事為人所記得。