掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
本文轉(zhuǎn)載自微信公眾號「JeffckyShare」,作者Jeffcky 。轉(zhuǎn)載本文請聯(lián)系JeffckyShare公眾號。

成都創(chuàng)新互聯(lián)公司一直秉承“誠信做人,踏實做事”的原則,不欺瞞客戶,是我們最起碼的底線! 以服務(wù)為基礎(chǔ),以質(zhì)量求生存,以技術(shù)求發(fā)展,成交一個客戶多一個朋友!為您提供成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、成都網(wǎng)頁設(shè)計、微信小程序定制開發(fā)、成都網(wǎng)站開發(fā)、成都網(wǎng)站制作、成都軟件開發(fā)、重慶App定制開發(fā)是成都本地專業(yè)的網(wǎng)站建設(shè)和網(wǎng)站設(shè)計公司,等你一起來見證!
個人以為,性能并非一次性就可完全成全,需結(jié)合實際業(yè)務(wù)有一個大致評估或預(yù)期,比如數(shù)據(jù)量大小,若預(yù)期短暫并不會達(dá)到性能瓶頸,大可不必過度考慮,又或者根據(jù)自我假想可能存在性能問題,于是大張旗鼓陷入自我意識流,最終可能結(jié)果吃虧反而不討好。
項目性能考慮
此前我個人寫過一版Excel導(dǎo)入和導(dǎo)出,并未使用對應(yīng)開源組件,因為導(dǎo)出和導(dǎo)入邏輯并不復(fù)雜,不涉及單元格拆分、包含圖片、下拉框等等,但處理起來也并沒有什么難度,借助NPOI或EPPLUS工具皆可滿足。
于是我嘗試將此前封裝Excel導(dǎo)入和導(dǎo)出做了進(jìn)一步重構(gòu)處理,主要為解決此前遺留問題:
其一:表頭列和實體屬性列順序必須一一對應(yīng)
其二:導(dǎo)出由于Excel單個Sheet行有限制,超出一定行,必須重建Sheet
其三:大量使用反射,若存在多個Sheet,且每個Sheet行數(shù)量稍微巨大,則存在一定性能瓶頸
如上兩點可以簡單解決,這里我們忽略,問題在于第三點,因為使用泛型,針對每一行讀取都會反射對象,同時也要獲取其實例屬性并賦值,這里我們完全可以改善下性能
接下來,我們通過一個簡單例子,來演示如何改善反射性能,當(dāng)然,也還有其他方案,這里我只介紹我個人的方案
反射性能改善
如一部分開源組件一樣,我們通過特性標(biāo)識屬性,屬性名稱和表頭列匹配,順序無需一致,同樣,屬性可忽略賦值
基于上述情況,我們要獲取對應(yīng)實體所標(biāo)識的屬性特性,這里為便于后續(xù)屬性賦值,我們緩存屬性相關(guān)信息,避免頻繁通過反射獲取屬性信息
接下來,我們來到屬性賦值和獲取,我們以設(shè)置值為例,獲取值同理,同時以1萬作為基數(shù)來驗證,然后以此基數(shù)遞增,如下測試實體
- public class Test
- {
- public int Id { get; set; }
- public string Name { get; set; }
- }
反射屬性賦值示例,如下:
- static void ReflectionExample(int count)
- {
- var stopWatch = new Stopwatch();
- stopWatch.Start();
- var tests = Enumerable.Repeat(new Test(), count).ToList();
- var propertyIdInfo = typeof(Test).GetProperty("Id");
- var propertyNameInfo = typeof(Test).GetProperty("Name");
- foreach (var test in tests)
- {
- propertyIdInfo.SetValue(test, 1);
- propertyNameInfo.SetValue(test, "jeffcky");
- }
- Console.WriteLine($"反射賦值耗時:{stopWatch.ElapsedMilliseconds}ms");
- }
當(dāng)然,根據(jù)筆記本配置以及所使用耗時方案不標(biāo)準(zhǔn),結(jié)果會存在差異,但基本可判斷反射耗時會有20ms以上
接下來,我使用委托方式來直接調(diào)用屬性Set方法,看看性能是否會有改善
- static void DelegateExample(int count)
- {
- var stopWatch = new Stopwatch();
- stopWatch.Start();
- var tests = Enumerable.Repeat(new Test(), count).ToList();
- var setId = (Action
)Delegate.CreateDelegate(typeof(Action ), null, - typeof(Test).GetProperty("Id").GetSetMethod());
- var setName = (Action
)Delegate.CreateDelegate(typeof(Action ), null, - typeof(Test).GetProperty("Name").GetSetMethod());
- foreach (var test in tests)
- {
- setId(test, 3);
- setName(test, "jeffcky");
- }
- Console.WriteLine($"委托賦值耗時:{stopWatch.ElapsedMilliseconds}ms");
- }
接下來,我們對比反射1萬條數(shù)據(jù)屬性賦值,看看耗時情況怎樣
通過運行多次,通過調(diào)用委托賦值其耗時基本可控制在5ms以內(nèi),想想差距還是有點大,接下來我們將數(shù)據(jù)量直接上升到100萬看看其差距
結(jié)果顯而易見,通過反射耗時將超過1s,而委托賦值則控制在幾十ms,如果再加上屬性的個數(shù)和獲取屬性值,耗時時間勢必將會再一次拉大
為何很多人都說反射性能很差,因為引入反射會通過如下幾步對性能有巨大損耗
其一:檢查所調(diào)用方法是否存在
其二:檢查其安全性和訪問可見性
其三:檢查簽名,確保所提供的參數(shù)和類型的數(shù)量與方法定義簽名一致
其四:解出參數(shù)
此文意非強調(diào)不能用反射,網(wǎng)上討論也很多,還是老話,根據(jù)實際業(yè)務(wù)情況,具體分析,別整體就惦記和揪著性能不放,比如針對快遞行業(yè),導(dǎo)入和導(dǎo)出操作可謂再正常不過,其導(dǎo)入數(shù)量也是龐大,對于此種情況,我們是否可考慮通過結(jié)構(gòu)體存儲數(shù)據(jù)呢?一切皆通過實際場景出發(fā)。
那么問題來了,寫本文的目的是什么呢?

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流