推薦：如何將 PHP 編譯成 .NET
內(nèi)容管理公司 Jadu 最近發(fā)布了一個(gè)工具，可以讓 PHP 和 .NET 這對(duì)冤家和平共處。他們開 發(fā)了一個(gè)叫做 Phalanger PHP compiler 的 工具，可以將 PHP 程序編譯成本地 .NET 程序執(zhí)行。他們還準(zhǔn)備將這一工具開源。 據(jù) Jadu CEO Suraj Kika 介紹，這個(gè)工具對(duì) PHP

在.NET平臺(tái)里，大部分編譯器的優(yōu)化并不是通過VB和C#編譯器來完成的。它們寧可把優(yōu)化的處理推后到CLR的即時(shí)（Just In Time，JIT）編譯器讀取IL，并轉(zhuǎn)換為原生機(jī)器碼的時(shí)候來完成。由于這個(gè)原因，對(duì)JIT的改變會(huì)極大地影響之前編譯好的程序集。

一個(gè)主要的影響就是內(nèi)聯(lián)函數(shù)（Inlining Function）調(diào)用。之前，JIT對(duì)內(nèi)聯(lián)方法的處理非常保守，Vance Morrison解釋了個(gè)中緣由，

它對(duì)內(nèi)聯(lián)的處理并不是很好。內(nèi)聯(lián)總是減少指令執(zhí)行的數(shù)量（這是由于最低限度的調(diào)用和返回指令沒有被執(zhí)行），但是它能（并經(jīng)常）讓結(jié)果代碼變得很大。大部分人都能直覺地理解，內(nèi)聯(lián)大的方法（比如1Kb的）不是很有意義，而內(nèi)聯(lián)非常小的方法可以讓調(diào)用的占用空間更�。ㄓ捎谡{(diào)用指令才5字節(jié)），這樣的選擇總是正確的，但是介于兩者之間的方法要如何處理呢？

有趣的是，當(dāng)你讓代碼變大時(shí)，你也就讓它執(zhí)行緩慢，因?yàn)閮?nèi)存天生地緩慢；你的代碼越大，它越不會(huì)放在最快的CPU緩存（稱之為L(zhǎng)1）里面執(zhí)行，在那樣的情況下，處理器需要執(zhí)行3-10個(gè)周期直到它能從另外的緩存（稱之為L(zhǎng)2）中獲取到執(zhí)行代碼，如果L2緩存中還不存在，那么就需要到主內(nèi)存中獲取（需要花費(fèi)10 周期）。對(duì)于在緊密循環(huán)中執(zhí)行的代碼，這樣的結(jié)果不會(huì)有什么問題，因?yàn)樗�有的代碼都適合放入到最快緩存中（典型的是64K），不過對(duì)于“常規(guī)的”代碼，它通過大量的方法來執(zhí)行大量的代碼，“越大就越慢”的效果就非常顯著。更大的代碼也就意味著在啟動(dòng)時(shí)從磁盤獲取代碼需要更大的磁盤I/O，這就意味著你的應(yīng)用程序啟動(dòng)較慢。

在Service Pack 1中，微軟引入了一個(gè)新的基于代碼尺寸的啟發(fā)式算法，來判斷調(diào)用是否處于一個(gè)循環(huán)中。在常規(guī)情況下，函數(shù)只有當(dāng)在調(diào)用空間中的結(jié)果機(jī)器碼比原始版本要小時(shí)，才能被內(nèi)聯(lián)。這樣做就保證了盡可能多的代碼能適合CPU的緩存，當(dāng)緩存不夠用時(shí)，就能對(duì)性能產(chǎn)生巨大的影響。

當(dāng)處在循環(huán)中時(shí)，分部異常也可以很好地工作。這是因?yàn)閾?jù)推測(cè)函數(shù)通常會(huì)被多次調(diào)用，所以CLR允許內(nèi)聯(lián)函數(shù)可以增長(zhǎng)至原始調(diào)用大小的5倍大。類似值類型優(yōu)化這樣的條件有可能更進(jìn)一步地增加容許尺寸的大小。

分享：談ASP.NET中XML數(shù)據(jù)的處理
SqlDataSource和ObjectDataSource控件都是平面表格式的數(shù)據(jù)源控件，操作也相對(duì)簡(jiǎn)單，在這里我就不細(xì)說了。 ASP.NET中XML數(shù)據(jù)是怎樣的處理呢？下面就詳細(xì)講解。 在這里我主要談下用于連接XML文件的XmlDataSource和用于連接站點(diǎn)導(dǎo)航數(shù)據(jù)的SiteMapDataSource這