標籤:visual number 詳細 動態 ref ros 實踐 net 存在
瞭解.net平台的兄弟都知道,.net也是採用動態編譯的
也就是說我們常說的build產生的dll只是中間代碼
而在web第一次請求的時候才是真正意義上的編譯產生二進位代碼
這也就是為什麼剛編譯完第一次開啟web頁面的時候會比較慢的原因
好了,閑話少扯
今天一個兄弟問我,為什麼他開發環境開啟編譯後的頁面越來越慢
下面是我的解決方案:
1.關掉inetinfo.exe的進程
2.關掉aspnet_wp.exe
3.關掉開啟的visual studio
4.清掉%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files檔案夾下的所有檔案。
%SystemRoot%指的是你的系統windows檔案夾的路徑,一般預設的是C:\WINDOWS\
整個清除過程可能會比較慢,具體時間和目錄下檔案夾大小有關。
清除完之後,第一次開啟還會比較慢,但是以後編譯後的開啟會快一些。
下面是詳細的解釋
當我們第一次請求的時候,也就是正式編譯的時候,dotnet會寫一些臨時檔案在這個檔案夾下。
這個本人驗證過,在第一次請求的時候,去關注檔案夾的變化。
對於部署在server已經上線的Web Application是不會存在這樣的問題的。
而在我們的開發環境下,由於經常要build,經常第一次請求,所以時間久了,這個檔案夾就會變得很大。
像我現在在做的項目,源檔案和目標檔案的大小有4G,那麼,寫到這個檔案夾裡的檔案就有上百兆。
我們可以去關注下,在選擇“附近到進程”操作之後載入的程式集,就是在這個路徑下。
不知道有的兄弟,會不會想,要經常手動去清這些檔案,豈不是很麻煩?
哈哈,想省事的兄弟,可以寫個批次程式來做這個操作。
這裡,我想介紹另一種方法來提升速度。
我們都知道,在我們可以控制的儲存單元中,記憶體的訪問速度是最快的。
如果,我們可以把這些臨時檔案放到記憶體中,就會成倍地提高速度。
1.安裝RamDisk
2.安裝好後,設定Debug 輸出的Temp 目錄為記憶體盤的path, 不再使用原來預置的 Temporary ASP.NET Files,只需要通過修改 Web.Config 檔案中的
<compilcation debug=”true”> 一般情況是這樣的
修改為 <compilcation debug=”true” tempDirectory=”R:\”>
保留原來屬性,新加一個 tempDirectory 指定記憶體盤的path
實踐檢驗,可以花費時間的差距可以到一個數量級。
擴充閱讀:http://msdn.microsoft.com/en-us/library/ms366723.aspx
Temporary ASP.Net Files探究