淺談.NET 3.5 SP1中的JIT增強_.Net教程
推薦:如何將 PHP 編譯成 .NET內容管理公司 Jadu 最近發布了一個工具,可以讓 PHP 和 .NET 這對冤家和平共處。他們開 發了一個叫做 Phalanger PHP compiler 的 工具,可以將 PHP 程序編譯成本地 .NET 程序執行。他們還準備將這一工具開源。 據 Jadu CEO Suraj Kika 介紹,這個工具對 PHP
在.NET平臺里,大部分編譯器的優化并不是通過VB和C#編譯器來完成的。它們寧可把優化的處理推后到CLR的即時(Just In Time,JIT)編譯器讀取IL,并轉換為原生機器碼的時候來完成。由于這個原因,對JIT的改變會極大地影響之前編譯好的程序集。
一個主要的影響就是內聯函數(Inlining Function)調用。之前,JIT對內聯方法的處理非常保守,Vance Morrison解釋了個中緣由,
它對內聯的處理并不是很好。內聯總是減少指令執行的數量(這是由于最低限度的調用和返回指令沒有被執行),但是它能(并經常)讓結果代碼變得很大。大部分人都能直覺地理解,內聯大的方法(比如1Kb的)不是很有意義,而內聯非常小的方法可以讓調用的占用空間更小(由于調用指令才5字節),這樣的選擇總是正確的,但是介于兩者之間的方法要如何處理呢?
有趣的是,當你讓代碼變大時,你也就讓它執行緩慢,因為內存天生地緩慢;你的代碼越大,它越不會放在最快的CPU緩存(稱之為L1)里面執行,在那樣的情況下,處理器需要執行3-10個周期直到它能從另外的緩存(稱之為L2)中獲取到執行代碼,如果L2緩存中還不存在,那么就需要到主內存中獲取(需要花費10 周期)。對于在緊密循環中執行的代碼,這樣的結果不會有什么問題,因為所有的代碼都適合放入到最快緩存中(典型的是64K),不過對于“常規的”代碼,它通過大量的方法來執行大量的代碼,“越大就越慢”的效果就非常顯著。更大的代碼也就意味著在啟動時從磁盤獲取代碼需要更大的磁盤I/O,這就意味著你的應用程序啟動較慢。
在Service Pack 1中,微軟引入了一個新的基于代碼尺寸的啟發式算法,來判斷調用是否處于一個循環中。在常規情況下,函數只有當在調用空間中的結果機器碼比原始版本要小時,才能被內聯。這樣做就保證了盡可能多的代碼能適合CPU的緩存,當緩存不夠用時,就能對性能產生巨大的影響。
當處在循環中時,分部異常也可以很好地工作。這是因為據推測函數通常會被多次調用,所以CLR允許內聯函數可以增長至原始調用大小的5倍大。類似值類型優化這樣的條件有可能更進一步地增加容許尺寸的大小。
分享:談ASP.NET中XML數據的處理SqlDataSource和ObjectDataSource控件都是平面表格式的數據源控件,操作也相對簡單,在這里我就不細說了。 ASP.NET中XML數據是怎樣的處理呢?下面就詳細講解。 在這里我主要談下用于連接XML文件的XmlDataSource和用于連接站點導航數據的SiteMapDataSource這
- asp.net如何得到GRIDVIEW中某行某列值的方法
- .net SMTP發送Email實例(可帶附件)
- js實現廣告漂浮效果的小例子
- asp.net Repeater 數據綁定的具體實現
- Asp.Net 無刷新文件上傳并顯示進度條的實現方法及思路
- Asp.net獲取客戶端IP常見代碼存在的偽造IP問題探討
- VS2010 水晶報表的使用方法
- ASP.NET中操作SQL數據庫(連接字符串的配置及獲取)
- asp.net頁面傳值測試實例代碼
- DataGridView - DataGridViewCheckBoxCell的使用介紹
- asp.net中javascript的引用(直接引入和間接引入)
- 三層+存儲過程實現分頁示例代碼
- 相關鏈接:
- 教程說明:
.Net教程-淺談.NET 3.5 SP1中的JIT增強。