為什麼很多程序員對string的執行效率耿耿於懷？

12-01

開發語言不限…

也只有C++吧，別的語言你不用string根本沒有選擇，所以就不會耿耿於懷了。有耿耿於懷是因為對比，但是很多搞C++的人明明連指針都用不好，就開始學大家談什麼性能，談什麼內存，談什麼string慢，殊不知他們的程序的bug多到都沒法用，隨便一搞漫天AV，還談什麼指標。

其實不單是c++。java裡面也是，許多人面試喜歡問String / StringBuilder / StringBuffer的區別，還有一個類似的就是ArrayList和LinkedList的區別。

其實對於99%的項目這些問題根本不需要擔心，省幾個ns真的那麼重要麼？甚至是像fb或者google這麼大的流量，在大部分情況下也不值得拿developer time來換cpu time。

過早優化是萬惡之源。

你以為Facebook的folly里有個fbstring是他們閑著蛋疼？

folly/folly/docs/FBString.md at master 路 facebook/folly 路 GitHub

對其他答案說string效率沒用的嗤之以鼻。輪子重造都是有原因的。隨便舉個例子：讀取debugfs下kernel用ftrace push出來的event然後序列化成JSON發送到其他daemon。

不知道所謂很多程序員都是什麼群體不過我們做acm比賽的時候似乎對這些東西特別敏感。。
類似的還有iostream和 i++
不知道是真的被這些東西的效率坑過還是只是理論上能快一點就強迫症發作

補充一下之所以提到stream是因為可以取消同步似乎就和stdio效率差不多了

c++ stl string 和java string比起來性能慢兩到三倍，辣雞

去掉「string」也一樣。
很多人對執行效率耿耿於懷，卻完全忽視開發效率和可維護性，更可氣的是優化不在點子上，弄出一堆堆bug出來坑人。。

首先這個東西的確不算慢。也的確很容易用成很慢。離開profile不說熱點談快慢也沒什麼意義。
對於非計算密集的系統慢的通常是io或者系統調用。知道這東西是什麼回事用時就會注意就很難用慢了。我們是不得不對這些被頻繁使用的東西耿耿於懷。事前寫時想多十秒性能評估一下或順手優化可以避免很多彎路。

原理上對於c++, std::string慢通常是因為賦值/拷貝構造和operator+這類新申請存儲或改變內部存儲布局的操作，這裡面有new和memcpy，相對慢。應該儘可能用const傳參，減少棧上的string對象創建和string對象修改（當然我說的是熱點，而不是你只會調用一兩次的那些個函數或循環）。而且通常跟它有關的表達式通常都會「偷偷」創建很多一次性的臨時string對象。
java的string的拼接也有類似問題，所以有stringbuffer這種東西來緩解，是吧……

不要怪用的人，程序員沒義務知道所有細節，而string的問題的確坑（反正c++整個都是坑），因此c++11覺得這坑不填不行，其move sematic直接提供便利，減少這種無意義的臨時string對象的構建，優化了這部分stl的實現。

說實話，我很反感一些人每看到一個點說就是哎呀，不行，效率低，執行慢。string，wstring提供給你是為了給你方便，你不喜歡自己可以封裝char*，wchar_t*是一樣的。再說了，以現在的機器標準，即使你大面積的使用string或者wstring，慢的問題也不會是出在這裡（曾經遇到過150MB左右的客戶端，使用的是string和wstring，依舊跑得好好的）。vczh已經說得狠明白了。

顯然是因為慢啊，快的話就不用耿耿於懷了……

好的工匠不會怪工具差，很多代碼工作者以為寫寫Hello word和計算器弄個函數寫個模塊就自稱程序員。渣渣。