→ freaky:你的問題蠻奇怪的，你真的確定memset是瓶頸嗎？ 04/05 04:32
→ freaky:一般來說應該是copy/reallocation太頻繁導致效能不佳 04/05 04:48
→ freaky:因為CArray是線性成長 04/05 04:50
推文不便抱歉中斷了。
我不太確定線性成長定義為何，但我知道一次是以 nGrowBy 為單位在增長。
這點和 vector 策略有異，然後的確 copy / reallocation 太差，所以改成
事先一次 SetSize 大一點的 Buf , 使 Add 機會變小 , 所以 trace 下來瓶
變 memset ( 約 1/5 時間 ) , 這點我待有環境時再確認過。
→ kiedveian:*(char**)((char*)&cary + 4) = (char*)pBuf; 04/05 12:25
→ kiedveian:這樣不知道行不行 04/05 12:25
這裡過了 ， 謝謝！！
推 dirkc:記得MFC有source，從那裡下手的可能性？另外所說的缺陷是指? 04/08 18:48
事後想，其實也不能說是 CArray 的缺陷，只是我想要省下一些時間。
(1) CArray::SetSize, vector::resize , 不論是哪一個，都有 memset
的動作 , 但我的例子根本就不用初始化。這點會計較，原因是記憶
體使用量大。
(2) 也由於記憶體使用量大，在智能成長，計算完後會再呼叫 FreeExtra，
但進去 trace code, 它的作法讓我蠻傻眼的，是先額外配置另外一份
新的記憶體，舊的填進去，新的拿來用，舊的再放掉。這在我的想法
應該用 realloc 就不一定會配置一份新的。
(3) 其實以我的例子來講，智能成長是以 vector 較為合適的，但這裡不論
是 vector / CArray，要自己動手利用內部現有的函式做配置策略，就
顯得有些繞路。
→ freaky:不建議改MFC，可以在呼叫端利用SetSize()改變成長曲線 04/08 19:22
→ freaky:線性成長y=Mx，x為成長次數，M為每次增加的element 04/08 19:24
→ freaky:Standard C++ Library的成長曲線是y=K^N 04/08 19:29
的確我也不敢改 MFC source code, 那裡不只我一個人在用而已。
最後還是放棄硬塞回去的念頭，最後做法如 freaky 所言，用
SetSize 做智能配置入口，原本是用
CArray<POD_TYPE,POD_TYPE> ary[ARY_CNT]; 除了先估
INT_PRT nGrowList[] 當智能策略外，還要再多份 INT_PTR nAryCount[ARY_CNT];
去記錄目前每份 array 的容量是多少，再來是增長失敗時的處理，
這些動作的確 CArray / vector 都做得到，只是記憶體用量已到極限，
要用包好的東西處理就顯得麻煩些了。
改完後的 Code ，效能的確提昇不少便是。謝謝各位關注 :D
※ 編輯: EdisonX (180.177.73.224), 04/08/2014 23:41:19