Julia 1.6 有哪些使人眼前一亮的光點？

Julia 1。6 很可能會成為 Julia 的下一個長期支援（LTS）版本。因此，我們投入了更多時間來開發這個版本，確保未來健康生態系統所需的各種特效能夠在該版本中實現。此外，我們還使用所有已註冊的開源軟體包對這個版本進行了迴歸測試，並跟蹤和解決了相關問題。在 Julia 1。6 經過實地測試後，大約 1。7 發行版進入穩定狀態時，我們將最終決定 1。6 是否將成為新的 LTS 版本。

一：並行預編譯

執行一個模組中所有語句的操作通常涉及大量程式碼的編譯，因此 Julia 建立了模組的預編譯快取以減少這部分時間開銷。在 1。6 中，這個包預編譯操作的速度更快了，並且發生在退出 pkg>模式之前。之前預編譯僅作為單個處理的序列，在第一次 using/import 一個軟體包時，線上性程式碼載入過程中需要時一對一地預編譯依賴項。

在 1。6 中，pkg>模式獲得了高度並行化的預編譯操作，該操作在程式包動作後自動呼叫，以使活動環境隨時可以載入。

二：編譯時間百分比

這個小更改應該能幫助新手理解 Julia 的一個怪癖：計時宏 @time 和它的冗長夥伴 @timev 現在會說明報告的時間中有多少是花在了編譯上

考慮到 Julia 的即時（JIT）/ 超前（JAOT）編譯機制，第一次執行程式碼時，編譯開銷通常非常可觀，而後續呼叫中可以看到很大的速度改進。這個更改會強調這種行為，可以作為一種提示，同時幫助消除不必要的編譯工作（例如過度針對性的程式碼）。

三：消除不必要的重編譯

Julia 最強大的特性之一就是它的可擴充套件性：你可以向先前定義的函式新增新方法，並對新型別使用先前定義的方法，有時，這些新實體會迫使 Julia 重編譯程式碼以解決分派中的更改。這裡分兩個步驟：第一，“過時的”程式碼被無效化，將其標記為不適合使用；第二，根據需要將新的方法和型別考慮在內，再次從頭開始編譯程式碼。

Julia 的早期版本有些保守，在某些情況下，分派中沒有實際更改，卻也會讓舊程式碼無效化。此外，在許多地方，Julia 及其標準庫的編寫方式都會破壞 Julia 的型別推斷。編譯器有時僅因為新方法“可能”被應用就被迫讓程式碼無效化，於是關於型別的任何不確定性都會放大無效化的風險和頻率。在 Julia 的舊版本中，這些影響加在一起讓無效化頻頻出現：只是載入某些程式包就會導致多達 10% 的 Julia 預編譯程式碼被無效化。重編譯的延遲有時會讓互動會話出現卡頓。當 Julia 的程式包載入程式碼中出現無效化時，它也延遲了下一個包的載入，那麼當 SomePkg 依賴其他包時，這就會延長 using SomePkg 的等待時間。

四：減少編譯器延遲

除了讓我們的庫程式碼對編譯器更友好之外，我們也在繼續嘗試加快編譯器本身的速度。這仍然是我們面臨的主要技術挑戰之一。在這一版本中沒有什麼重大突破，但是我們確實做了一些適度的改進，對方法表資料結構做了最佳化。

五：幫助最佳化包延遲的工具鏈

Julia 1。6 與 SnoopCompile v2。2。0 或更高版本共同提供了用於編譯器自省的新工具，尤其是（但不僅限於）針對型別推斷的用途，開發人員可以使用新工具來分析型別推斷，並確定特定的包實現選項如何與編譯時互動。早期採用者已使用這些工具降低了首次使用的延遲，幅度從百分之幾到大部分延遲不等。

六：二進位制載入加速

為包提供可靠的可移植二進位制檔案是所有包環境都必須面對的一項挑戰，儘管 Julia

的

策略一直是將可靠性和可重現性放在所有問題的首位，但之前這一選擇是有不小代價的。我們針對可靠性和可重現性的解決方案是完全隔離已安裝的二進位制檔案，並使用 BinaryBuilder。jl 框架來交叉編譯它們。從 BinaryBuilder。jl 構建的庫往往透過所謂的 JLL 包來使用，這個包提供了一個標準化 API，Julia 包可以用它來訪問給定的二進位制檔案。在過去，Julia 包會盲目地 dlopen（） 庫並載入庫搜尋路徑中的任何庫，導致載入時間暴漲，相比之下新方法的載入時間有了顯著縮短。舉個例子，在 Julia 1。4 中，載入 GTK+3 堆疊需要 7 秒鐘，而以前在同一機器上約需 500 毫秒。經過數月的艱苦努力和仔細調查，我們很高興地報告，在同一機器上使用 Julia v1。6 時，同一庫堆疊現在只需不到 200 毫秒 的載入時間。

七：下載和網路選項

在之前的版本中，當你使用 Base。download 函式直接在 Julia 中下載內容時，或者使用 Pkg 間接下載時，實際的下載過程是由某些外部過程完成的，可能是 curl、wget、fetch 或是 PowerShell，系統中有哪個就用哪個。這種方法能行得通其實挺不可思議的，實際上它的背後是多年來積累的很多複雜命令列選項調整。

八：CI 穩健性

在這個釋出週期中，我們花費了大量時間以持續整合（CI）過程中間歇測試失敗的形式償還技術債務。就像如今所有負責任的軟體專案一樣，我們為每次提交和更改提案執行完整的構建和測試套件。如果測試失敗，則可以停止釋出，直到問題解決——解決問題的辦法可以是還原更改、提交新的修補程式或修訂提案的補丁程式直到透過為止。但這確實是發生在我們身上的事情：隨著時間的流逝，我們最終陷入了很大比例的測試都執行失敗的境地，這些失敗通常只是因為一個不起眼的測試用例失敗。

九：改進的 stacktrace 格式

在 Julia 0。6 的時候，堆疊跟蹤的格式做了大修。而在新版本中，@jkrumbiegel 在這一方面做了進一步改進（在 #36134 中實現）。