爲什麼val + = someOtherValue如此糟糕？

爲什麼做得如此糟糕？爲什麼val + = someOtherValue如此糟糕？

String val = null; 
String someOtherValue = "hello" 

val += someOtherValue;

它一定很壞，但爲什麼呢？我的程序中有這條線，它極大地減緩了一切！

我假設這是因爲它不斷重新創建字符串？這是唯一的原因嗎？

來源

2012-03-26 BigBug

「非常」多少？你執行過多少次（循環）？如果您不*附加'someOtherValue'，您的程序是否會有不同的操作？ – 2012-03-26 04:19:23

你是如何確定它是唯一會減慢程序速度的東西？ – krammer 2012-03-26 04:20:24

到一切都凍結了！我正在解析圖像中的值，因此對於圖像中的每個像素（3個字節大），我追加了一個單獨的值。我追加的值的大小是每次1字節大...我改爲使用列表，現在它不凍結。 – BigBug 2012-03-26 04:21:41

確切的代碼非常好;編譯器會優化它。

這樣做在循環可能會很慢，因爲這會爲每個級聯創建一個單獨的（不可變的）string對象。

改爲使用StringBuilder。

來源

2012-03-26 04:20:10 SLaks

使用StringBuilder還是使用字符串列表更好？爲什麼？ – BigBug 2012-03-26 04:23:04

@BlueMonster：沒關係。如果您正確設置容量（以避免調整大小），StringBuilder應該更快一點 – SLaks 2012-03-26 04:32:32

是的，原因是字符串在C＃中是不可變的，這意味着它們不能被改變。該框架被強制每次你做一次分配一個新的字符串+ = 嘗試使用StringBuilder的，而不是..

所不同的是在長期循環非常明顯

來源

2012-03-26 04:20:11 TGH

使用StringBuilder還是使用字符串列表更好？爲什麼？ – BigBug 2012-03-26 04:22:55

請注意，如果使用簡單concat（s1 + s2）少於7次，它仍然更便宜。 – SimpleVar 2012-03-26 04:22:55

@BlueMonster string.Join（「」，strs）比SB好，但不是太多。對它進行測試相當簡單。 – SimpleVar 2012-03-26 04:23:54

我不認爲有一個銀色子彈「這比這更好」。這取決於您需要連接字符串的場景。性能與可讀性在這裏也是一個問題。有時候最好通過在性能上做一些妥協來編寫一個可讀性很好的代碼。

參照的article從詹姆斯邁克爾野兔

的事實，則concattenation運算符（+）已被用於速度優化，並看起來乾淨在接合在一起一組已知串最簡單的方式。

另一方面，StringBuilder在您需要構建字符串的不確定長度時很出色。當你在循環時，使用它，直到你達到停止條件，並建立一個結果，它不會誤導你。

String.Format似乎是從統計數據中鬆散，但考慮其中哪些更可讀。是的，忽略這樣一個事實，即您可以使用DateStyle上的ToString（）來執行此操作。

看一看article，值得一看。

來源

2012-03-26 06:30:31 ABH

謝謝，這個答案真的幫助:) – BigBug 2012-03-26 06:52:32

爲什麼val + = someOtherValue如此糟糕？

回答

相關問題