程式設計社群正在重新審視一項數十年前的排序優化技術，這是由對現代語言如何處理昂貴鍵值轉換的全新分析所引發。討論焦點圍繞著 Schwartzian Transform ，這是一個在1990年代從 Perl 程式設計中出現的巧妙排序演算法，以及它與當今開發環境的相關性。
Schwartzian Transform 演算法步驟：
- 裝飾：將原始值與計算出的排序鍵組合成元組
- 排序：基於元組中計算出的鍵進行排序
- 去裝飾：從排序後的元組中提取原始值
這種模式將昂貴的鍵計算複雜度從 O(n log n) 降低到 O(n)。
語言效能差異巨大
最近對熱門程式語言進行的測試揭示了排序效率方面令人驚訝的不一致性。雖然 C# 會自動優化排序，每個項目的轉換函數只評估一次，但其他主要語言如 Java 、 Rust 的預設 sort_by_key() 和 C++20 在排序操作期間會重複呼叫昂貴的轉換函數。這意味著在沒有內建優化的語言中，排序1,000個項目可能會觸發轉換函數數千次，而不是最佳的1,000次。
當處理昂貴的操作如檔案系統呼叫、資料庫查詢或複雜計算時，效能差距變得至關重要。使用這些語言的開發者必須手動實作 Schwartzian Transform 模式才能達到最佳效能。
語言排序效能比較：
- C：每個項目僅評估一次轉換函數（已優化）
- Java：使用 Comparators ，重複呼叫轉換（未優化）
- Rust sort_by_key()：多次呼叫轉換（未優化）
- Rust sort_by_cached_key()：實作進階快取機制，在已排序輸入上達到線性時間（高度優化）
- C++20 std::range：重複呼叫 lambda （未優化）
可讀性與效能的爭論再次浮現
社群討論揭示了程式碼可讀性與效能優化之間持續存在的緊張關係。1990年代圍繞 Schwartzian Transform 的原始爭議集中在程式語言是否應該優先考慮立即理解性或強大功能性。這場辯論至今仍在繼續，一些開發者主張明確、冗長的解決方案，而另一些則擁抱簡潔的函數式程式設計模式。
「我覺得有趣的是這個轉換在90年代是有爭議的。對我來說，今天它似乎是這個問題的正常解決方案，爭議顯得很愚蠢。」
具有 JavaScript 和函數式程式設計概念經驗的現代開發者通常覺得這種模式很直觀，而來自命令式程式設計背景的開發者可能仍然偏好傳統的迴圈方法。
 |
|---|
| Schwartzian Transform 的歷史：深入了解該演算法的背景以及相關的程式設計辯論 |
Rust 以雙重方法領先
在測試的語言中， Rust 透過提供 sort_by_key() 和 sort_by_cached_key() 兩種方法展現了最周到的做法。快取版本實作了一個超越基本 Schwartzian Transform 的精密演算法，在已排序輸入上達到線性時間效能，同時維持高效的記憶體使用。這種雙重方法承認大多數排序操作涉及簡單、便宜的轉換，不需要快取，同時仍為昂貴操作提供優化解決方案。
程式設計社群對這個經典優化技術的重新關注突顯了基礎演算法概念如何在不同語言世代中保持相關性。隨著應用程式處理越來越複雜的資料轉換，理解和實作高效排序策略對於注重效能的開發變得至關重要，無論選擇何種程式語言。