今天週末，就不寫太長的文章了，剛不小心看了篇效能比較的文章，有感而就寫了此篇。
這年頭，好多人都對效能比較產生了興趣，然後就開始寫比較示例，之後就得出了乙個正確但誤導新手的誤區。
這裡舉較常見的說：
1：string和stringbuilder
2：反射和emit
3：==和string.equals
通常比較都怎麼比？
1：寫個測試示例
2：for它箇10萬百萬次
3：看輸出時間
4：得出結論
結論與「推薦」
後者速度比前者速度快了n倍，然後就開始「推薦」使用後者。
然後就盲目「推薦」給自己和周圍的人士。
廣泛「推薦」及人推人之後的現象
於是現在看很多人的**，都喜歡：
動不動就來個stringbuilder。
動不動就來下emit。
動不動就來次string.equals。
看文章請認準效能臨界點
什麼是臨界點，下面是乙個精略的估算次數：
600次迴圈之前，string比stringbuilder快。
500次迴圈之前，反射比emit快。
90000000的迴圈，才換來：1.6392576秒和1.1163117秒間46.675%的效能差別。
應用應該看場景
別動不動就在stringbuiler，或以磚家的身份還在嫌人家的string+="***"慢。
別動不動就在emit，雖然寫emit是個相對難以理解和編寫的。
別動不動就在string.equals,難道你的**真會迴圈9千萬次？
簡單說句是什麼？
認準你的**的應用場景，是否會產生大於n百次的臨界點，再決定使用哪個。
再簡單？
通常你的string迴圈不會超過600次,老實的用string+=「」。
通常你的list的集合不會超過500條，老實的用反射。
通常你的==沒什麼問題，該用就用。
附加：
最近發布了：cyq.data 資料框架 v4.5版本，歡迎收看與使用。
幾種toString的效能比較
最近要寫乙個批量的介面，由於一次請求的量比較大，所以很多小的點不得不好好考慮效能。乙個object的tostring操作，也是乙個效能考慮點，故自己做了乙個測試，比較了一下可能的幾種tostring的方式。public static void main string args long endtim...
關於幾種排序演算法的時間效能比較
以前經常看到各種排序演算法，今天也對以下6種排序演算法的時間效能做了一次測試 測試 位址 1.氣泡排序 o n 2 氣泡排序 param arr 整形切片 func bubblesort arr int 2.插入排序 o n 2 插入排序 param arr 整形切片 func insertsort...
關於效能測試中的併發
不少負載工具在實際的意義中也可以進行壓力測試的分析。其中經常談到併發及集合點的概念。集合點是為了大資料量的指令碼，設定1個集合點，利於指令碼分批量執行，也近似模擬乙個較真實的場景。併發目的引入併發是為了提高資源利用率，從而提高系統效率。併發是1個會受作業系統所影響，是指在單位一定時間內的執行內 物理...