當前位置:
首頁 > 知識 > 是什麼讓 .Net Core 性能碾壓傳統 .Net(二)?

是什麼讓 .Net Core 性能碾壓傳統 .Net(二)?

是什麼讓 .Net Core 性能碾壓傳統 .Net(二)?


序列化

二進位序列化是.NET的另一個領域。BinaryFormatter最初並不是.NET Core中的一個組件,但是它包含在.NET Core 2.0中。該組件在性能方面有比較巧妙的修復。例如,PR dotnet / corefx#17949是一種單行修復,可以增加允許增長的最大大小的特定數組,但是這一變化可能對吞吐量產生重大影響,通過O(N)演算法比以前的O(N ^ 2)演算法要話費更長的操作時間。以下代碼示例,明顯的展示了這一點:

using System;using System.Collections.Generic;using System.Diagnostics;using System.IO;using System.Runtime.Serialization.Formatters.Binary;class Test

在.NET 4.7中,代碼輸出如下結果:

76.677144

而在.NET Core 2.0中,會輸出如下結果:

6.4044694

在這種情況下顯示出了12倍的吞吐量提高。換句話說,它能夠更有效地處理巨大的序列化輸入。


文字處理

.NET應用程序中另一種很常見的計算形式就是處理文本,文字處理在堆棧的各個層次上都有大量的改進。

對於正則表達式,通常用於驗證和解析輸入文本中的數據。以下是使用Regex.IsMatch重複匹配電話號碼的示例:

using System;using System.Diagnostics;using System.Text.RegularExpressions;public class Test

在個人計算機上,.NET 4.7會得到的如下結果:

Elapsed=00:00:05.4367262 Gen0=820 Gen1=0 Gen2=0

而使用.NET Core 2.0會得到如下結果:

Elapsed=00:00:04.0231373 Gen0=248

由於PR dotnet / corefx#231的變化很小,這些修改有助於緩存一部分數據,因此吞吐量提高了25%,分配/垃圾收集減少了70%。

文本處理的另一個例子是各種形式的編碼和解碼,例如通過WebUtility.UrlDecode進行URL解碼。在這種解碼方法中,通常情況下輸入不需要任何解碼,但是如果輸入經過了解碼器,則輸入仍然可以通過。感謝來自hughbe的 PR dotnet / corefx#7671,這種情況已經被優化了。例如下面這段程序:

using System;using System.Diagnostics;using System.Net;public class Test

在.NET 4.7中,會得到以下輸出:

Elapsed=00:00:01.6742583 Gen0=648

而在.NET Core 2.0中,輸出如下:

Elapsed=00:00:01.2255288 Gen0=133

其他形式的編碼和解碼也得到了改進。例如,dotnet / coreclr#10124優化了使用一些內置Encoding -derived類型的循環。例如下面的示例:

using System;using System.Diagnostics;using System.Linq;using System.Text;public class Test

在.NET 4.7中得到以下輸出,如:

00:00:02.4028829

而.NET Core 2.0等到如下輸出:

00:00:01.6133550

這些改進也適用於字元串和其它類型之間轉換,例如.NET中生成Parse和ToString方法。使用枚舉來表示各種狀態是相當普遍的,例如使用Enum.Parse將字元串解析為相應的枚舉。PR dotnet / coreclr#2933改善了這一點。請查看以下的代碼:

using System;using System.Diagnostics;public class Test

在.NET 4.7中,會得到的以下結果:

Elapsed=00:00:00.9529354 Gen0=293

在.NET Core 2.0上,會得到以下結果:

Elapsed=00:00:00.6448327 Gen0=11

不但吞吐量提高了約33%,而且分配和相關垃圾收集也減少了約25倍。

當然,在.NET應用程序中需要進行大量的自定義文本處理,除了使用像Regex / Encoding這樣的內置類型和Parse和ToString這樣的內置操作之外,文本操作通常都是直接構建在字元串之上,並且大量的改進已經引入到了操作on String之上。

例如,String.IndexOf很擅長於查找字元串中的字元。IndexOf在bnetyersmyth的dotnet / coreclr#5327中得到改進,他們為String實現了一系列的性能改進。正如下面的例子:

using System;using System.Diagnostics;public class Test

在.NET 4.7上,會得到如下結果:

00:00:05.9718129

而在.NET Core 2.0中,會得到如下結果:

00:00:03.1283763

吞吐量提高約2倍。

下面是比較字元串部分。這是一個使用String.StartsWith和序數比較的例子:

using System;using System.Diagnostics;using System.Linq;public class Test

在.NET 4.7上會得到如下結果:

00:00:01.3097317

.NET Core 2.0會得到如下結果:

00:00:00.6239002

對String的改進,也讓我們看到對於其它方面進行更多改進的可能性,這是非常有趣的。


文件系統

到目前為止,本文一直專註於內存中操縱數據的各種改進。但是.NET Core的許多更改都是關於I / O的。

下面從文件開始介紹。這是一個從文件中非同步讀取所有數據並將其寫入另一個文件的示例:

using System;using System.Diagnostics;using System.IO;using System.Threading.Tasks;class Test

FileStream中的開銷也在進一步減少,例如DOTNET / corefx#11569增加了一個專門的CopyToAsync實現,dotnet/ corefx#2929也改進了非同步寫入的處理,.NET 4.7會得到如下結果:

Elapsed=00:00:09.4070345 Gen0=14 Gen1=7 Gen2=1

.NET Core 2.0會得到如下結果:

Elapsed=00:00:06.4286604 Gen0=4 Gen1=1 Gen2=1

網路

網路是值得關注的部分,這部分也將取得很大的改進。目前正在付出很大的努力來優化和調整低等級的網路堆棧,以便高效地構建更高級別的組件。

這種改變帶來的一個很大的影響是PR dotnet / corefx#15141。SocketAsyncEventArgs是Socket上大量非同步操作的核心,它支持同步完成模型,因此非同步操作實際完成了同步操作,這樣避免了非同步操作的分配消耗。但是,.NET 4.7中的同步操作運算是失敗的, PR修復了上述的實現問題,允許在socket上進行所有非同步操作的同步完成。這樣的提升在以下代碼中變現的非常明顯:

using System;using System.Diagnostics;using System.Net;using System.Net.Sockets;using System.Threading;using System.Threading.Tasks;class Test

該程序創建兩個連接的socket,然後向socket寫入1000次,並且在案例中使用非同步方法接收,但絕大多數操作將同步完成。在.NET 4.7中會得到如下結果:

Elapsed=00:00:20.5272910 Gen0=42 Gen1=2 Gen2=0

在.NET Core 2.0中,大多數操作能夠同步完成,得到如下結果:

Elapsed=00:00:05.6197060 Gen0=0 Gen1=0 Gen2=0

不僅僅是直接使用socket來實現組件的這種改進,而且還通過更高級別的組件來間接使用socket,其他PR的結果是更高級別組件(如NetworkStream)的額外性能提升。例如,PR dotnet / corefx#16502在SocketAsyncEventArgs上重新實現了基於Socket的SendAsync和ReceiveAsync操作,並且允許它們在NetworkStream中使用。Read / WriteAsync和PR dotnet / corefx#12664添加了一個專門的CopyToAsync重寫,以便更有效地從NetworkStream讀取數據並將其複製到其他流中。這些變化對NetworkStream吞吐量和分配有非常大的影響。看看下面這個例子:

using System;using System.Diagnostics;using System.IO;using System.Net;using System.Net.Sockets;using System.Threading;using System.Threading.Tasks;class Test

與之前的Socket一樣,下面我們創建兩個連接的socket,然後把它們包含在NetworkStream中。在其中一個流中,我們將1K數據寫入一百萬次,而另一個流則通過CopyToAsync操作讀出所有數據。在.NET 4.7中,會得到如下輸出:

Elapsed = 00:00:24.7827947 Gen0 = 220 Gen1 = 3 Gen2 = 0

而在.NET Core 2.0中,時間減少了5倍,垃圾回收有效地減少到零:

Elapsed=00:00:05.6456073 Gen0=74 Gen1=0 Gen2=0

其它網路相關組件也將得到進一步優化。例如SslStream通常將圍繞在NetworkStream中,以便向連接中添加SSL。下面的示例將看到這種影響,這個示例將在NetworkStream之上添加SslStream的用法:

using System;using System.Diagnostics;using System.Threading;class Test

在.NET 4.7中,會得到如下結果:

Elapsed=00:00:21.1171962 Gen0=470 Gen1=3 Gen2=1

.NET Core 2.0包含了諸如dotnet / corefx#12935和dotnet / corefx#13274等PR的改進,這兩者都將大大減少了使用SslStream所涉及的分配。在.NET Core 2.0上運行相同的代碼時,會得到如下結果:

Elapsed=00:00:05.6456073 Gen0=74 Gen1=0 Gen2=0

85%的垃圾收集已被刪除!


並發

對於並發和並行性相關的原始化和基礎部分,也得到了許多改進。

這裡的一個關鍵點是ThreadPool,它是執行許多.NET應用程序的核心。例如,PR dotnet / coreclr#3157減少了QueueUserWorkItem中涉及的某些對象的大小,PR dotnet / coreclr#9234使用了ConcurrentQueue 重寫來替換ThreadPool的全局隊列,其中會用到較少的同步和分配。從以下的示例中,會看到最終結果:

using System;using System.Diagnostics;using System.Threading;class Test

在.NET 4.7中,會等到如下結果:

Elapsed=00:00:03.6263995 Gen0=225 Gen1=51 Gen2=16

而在.NET Core 2.0中,會得到如下結果:

Elapsed=00:00:02.1797508 Gen0=153 Gen1=0 Gen2=0

這是一個巨大的吞吐量的改善,並且這樣一個核心組件的垃圾量也將大幅減少。

同步原語也在.NET Core中得到提升。例如,低級並發代碼通常使用SpinLock來嘗試避免分配鎖定對象或最小化競爭鎖所花費的時間。PR dotnet / coreclr#6952改進了失敗的快速路徑,以下測試會得到顯而易見的結果:

using System;using System.Diagnostics;using System.Threading;class Test

在.NET 4.7中,會得到如下結果:

00:00:02.3276463

而在.NET Core 2.0中,會得到如下結果:

00:00:00.3915327

吞吐量的這種差異可能會對運行這種鎖的熱路徑產生很大的影響。

這只是眾多例子中的一個。另一個例子圍繞著Lazy,它被PR dotnet / coreclr#8963用manofstick重寫,以便提高訪問初始化過的Lazy 的效率。這樣的提升效果從下面的示例中清晰可見:

using System;using System.Diagnostics;class Test

在.NET 4.7中,會得到的結果如下:

00:00:02.6769712

而在.NET Core 2.0中,會得到的結果如下:

00:00:00.5278348

吞吐量增加約5倍。


下一步是什麼

本文只涉及了部分.NET Core的性能改進。在dotnet / corefx和dotnet / coreclr repos 中的pull請求中搜索「perf」或「performance」,你會發現接近一千個合并的PR改進。其中一些是比較大的同時也很有影響力的改進,而另一些則主要減少了庫和運行時的消耗,這些變化一起起作用,保證了能夠在.NET Core上更快的運行應用程序。展望未來,性能將成為關注的重點,無論是以性能改進為目標的API還是現有庫的性能的改進。

歡迎大家深入了解.NET Core代碼庫,以便找到影響自己的應用程序和庫的瓶頸,並提交PR來修復它們。如果你的問題得到修復,也請將修復程序分享給所有需要的人。

轉載請註明出自:葡萄城控制項


關於葡萄城

葡萄城是全球控制項行業領導者,世界領先的企業應用定製工具、企業報表和商業智能解決方案提供商,為超過75%的全球財富500強企業提供服務。

喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 葡萄城控制項 的精彩文章:

是什麼優化讓 .NET Core 性能飆升?
還在為畫「類Word文檔報表」而發愁嗎?
多維透視表-矩表實現商品銷售對比統計
免費報表庫,萬元大禮包!葡萄城報表福利大放送

TAG:葡萄城控制項 |

您可能感興趣

還要什麼紅米Note 7 Pro?Realme X全面碾壓
碾壓Supreme聯名系列再爆新配色!這款Nike Zoom Sreak Spectrum Plus你怎麼看?
碾壓Supreme聯乘鞋款?「Gucci」配色加持的Nike Air Zoom Alpha,考慮下?
氣勢碾壓Supreme?PALACE x Polo Ralph Lauren首波型錄曝光!
余承東穩了?結果iPhone Xs碾壓華為Mate20Pro
顏值碾壓Supreme聯乘?Air Jordan 5 新配色曝光!
beats x無線藍牙耳機憑什麼碾壓airpods?和powerbeats3 wireless如何PK?夢之藍海心
瞬間碾壓「煙花噴」?這雙「換勾泡」 NIKE Air Foamposite Pro讓你大玩定製!
性能差異需要升級嗎?iPhoneXR暴力碾壓iPhone8+
iMazing - 功能全面碾壓 iTunes 的 iPhone 手機管理器-提供軟體
實力碾壓「北卡藍」?!客製版「酷炫黃」Virgil Abloh x Nike Air Jordan 1勁爆登場!
實力碾壓「北卡藍」!客製版「酷炫黃」Virgil Abloh x Nike Air Jordan 1勁爆登場!
希捷LaCie Rugged Secure 2TB移動硬碟開箱圖賞:不怕汽車碾壓
蘋果A12沒那麼強 iPhoneSE暴力碾壓iPhoneXR
iPhone X又被吊打,不過這次華為P20 Pro是憑藉實力碾壓的
5行代碼秀碾壓,比Keras還好用的fastai來了,嘗鮮PyTorch 1.0必備伴侶
Super carry!rw中單doinb克列碾壓韓國隊,全場沸騰!
Lucid Motors:實力碾壓特斯拉?
顏值輕鬆碾壓CdG聯名款!全貌ACRONYM x VaporMax Moc 2還真不是一般酷!
驍龍845再遭碾壓?iPhone X和Galaxy S9+性能對比評測