500k行.net應用程序需要多長時間才能加載？

假設我有一個用原生C++編寫的應用程序（超過50萬行代碼），我想將它移植到.NET（C＃）。我擔心的一件事是JIT編譯器。它需要我的本地代碼編譯器超過30秒才能編譯。這是否意味着每次用戶啓動我的C＃應用程序時，都需要很長時間才能加載它（因爲JIT編譯器必須每次都編譯它）？500k行.net應用程序需要多長時間才能加載？

來源

2010-09-15 C. Smith

出於興趣花費所有時間移植到C＃的好處是什麼？ C＃提供了什麼C++不？ – 2010-09-15 15:51:17

我不能討論任何細節。抱歉。 – 2010-09-15 16:07:54

從你想的意義上說，JIT編譯器不太「編譯」。它需要時將一個指令集（IL字節碼）轉換爲另一個（x86或x64機器碼）。轉換的設計非常簡單，只要C++編譯應用程序就不需要任何附件。它甚至不會一次全部發生（「及時」意味着指令在大約執行時被翻譯），因此應用程序將很快啓動。

編譯困難且耗時的部分是從人類可讀指令（源代碼）到機器可讀指令（字節碼或本地代碼，取決於您的語言/平臺）的轉換。該部分在創建EXE時已經完成，除非源代碼（或其含義）改變，否則不需要重做。

來源

2010-09-15 15:47:41 cHao

我可以說JIT這些日子裏簡直就是簡單明瞭，而且還有簡介指導的優化。 – 2010-09-16 03:04:40

當您試圖在飛行中優化時會變得複雜。但IL->本地翻譯的基本過程被設計爲快速和直接。 – cHao 2010-09-16 03:39:16

-1

這取決於很多因素，沒有足夠的信息可以知道，只是給出本地代碼編譯器編譯所需的時間並不能提供足夠的信息。取決於應用程序在做什麼，可能需要從30秒到幾個小時。

來源

2010-09-15 15:30:48 sange

這個問題關於運行時「編譯」（即：字節碼 - >本地代碼翻譯），它不需要接近30秒。編譯中最難的部分（解析源代碼並將其轉換爲機器可讀指令）在運行前已經完成，並且不需要每次都重新執行。 – cHao 2010-09-15 15:42:55

.NET程序集加載器將按需加載程序集。他們已經準備好在CLR虛擬機字節碼中運行。任何發生的JIT都可以根據需要調用的代碼路徑按需和零散地進行。（換句話說，小快塊，它可能不會發生在所有代碼上）。

我不擔心JIT。確保應用程序是模塊化的，並熟悉分析工具，以便在遇到這些應用程序時確定速度減慢。

來源

2010-09-15 15:31:44

這不是JIT編譯的工作方式。

C＃應用程序將被預編譯成一個字節碼，它本身包含許多優化。

JIT編譯的名稱爲「Just In Time」。這意味着它只將部分字節碼編譯爲本地代碼，根據需要，而不是整個應用程序。

這樣做的一個結果是運行時分析可以提高長時間運行的應用程序的性能。

來源

2010-09-15 15:31:54 Randolpho

您的應用程序將立即開始運行JIT編譯器在調用之前不會編譯代碼，而不是全部預先編譯。其次，如果您的應用程序啓動時間太慢，那麼您可能需要查看Ngen，它將本機圖像緩存中的程序集編譯和存儲。

來源

2010-09-15 15:51:18 stonemetal

對於一些長時間運行的CPU密集型應用程序，JIT實際上具有性能優勢*。

1）類的方法在它們被首次使用
2）對於很多應用將改善代碼局部性（recude CPU高速緩存未命中）
*的順序JIT'ed - 應用與這些品質往往是服務器端

但是如果啓動時間是您關心的問題，那麼NGen至少包含啓動代碼的程序集（如果它可以被隔離），因爲啓動代碼通常只加載一次，並且不會受益於按需區域JIT。

過去幾年CLR改進的好處在於緩解了一些大型啓動性能問題，如基地址衝突（請參閱http://msdn.microsoft.com/en-us/magazine/dd569747.aspx）和像NGen這樣的工具改進以減少開銷（應用程序安裝後的NGen時間已經減少）。如果您使用.NET 3.5並擔心啓動時間，則可能需要在運行32位和64位時進行測量，因爲JIT在.NET 4之前的x86/x64具有非常不同的後端。

來源

2010-09-16 03:01:21 yzorg

500k行.net應用程序需要多長時間才能加載？

回答

相關問題