注意線程安全啊  回復(fù)  更多評論
  

@水
這個知道, 誰使用誰負責線程間數(shù)據(jù)一致性, 我這個主要負責提高性能, 同一進程內(nèi)可以使用臨界區(qū), 互斥量, 信號量等等. 不同進程使用互斥量, 信號量等, 推薦使用信號量.
  回復(fù)  更多評論
  

你這個實現(xiàn)快了多少呢？能分析一下為什么會快嗎？  回復(fù)  更多評論
  

在我的項目里, 至少提高了 3 倍以上, 當然沒有具體的測試數(shù)據(jù), 只是目測. 你有興趣可以試試. 呵呵. 當然, 還有其他的改進, 比如, 將內(nèi)核級的信號量改成用臨界區(qū), 因為只有進程內(nèi)部共享數(shù)據(jù). 無進程間通訊的需求.  回復(fù)  更多評論
  

1、快在哪？
2、如果T重載了operator =，那insert里的*(m_pArray+nPos)=element;是非常危險的；
3、模板類應(yīng)該慎用mem*系列函數(shù)；
4、……
  回復(fù)  更多評論
  

"sage_ulti"
這個是不是"sage_util"？  回復(fù)  更多評論
  

@土
第一, 我僅僅是讓我的工作高效的完成. 而設(shè)計一個簡單的類, 不是要設(shè)計一個工業(yè)強度的庫.
第二, 危險不危險各人心中有數(shù). 崩掉了自己會找到原因的.
第三, 交流心得就交流心得, 你覺得你高明自個兒寫文章去, 這里不容納你的排泄物.   回復(fù)  更多評論
  

@木
毫無意義, 你可以將這個名字空間換成你的, 甚至將其完全刪除  回復(fù)  更多評論
  

這回復(fù)貌似是一個人 金木水火土都要快齊了  回復(fù)  更多評論
  

不錯.....不過同一進程內(nèi)可以使用臨界區(qū), 互斥量, 信號量等等. 不同進程使用互斥量, 信號量等, 推薦使用信號量. ??

是什么意思啊??
可以說明白嗎?為什么在線程時要這樣呢??不太明白,希望可以講下..謝謝!  回復(fù)  更多評論
  

@RichardHe
多線程同步的問題, 建議找本侯捷翻譯的《Win32多線程程序設(shè)計》書看看, 里面有你想要的.
  回復(fù)  更多評論
  

不要和 vc6 的比. 你試試 sgi stl.

#define REPEAT_COUNT 100000000

void main()
{
DWORD dwStart = 0;

vector<int> vint;
vint.reserve(REPEAT_COUNT);
dwStart = GetTickCount();
for (int i = 0; i < REPEAT_COUNT; i ++)
vint.push_back(i);
cout << GetTickCount() - dwStart << endl;


ArrayDynamic<int> intArray(REPEAT_COUNT);
dwStart = GetTickCount();
for ( i = 0; i < REPEAT_COUNT; i ++)
intArray.push_back(i);
cout << GetTickCount() - dwStart << endl;

}

output:

6790
10785  回復(fù)  更多評論
  

上面的例子，用VC9試了一下

1078
3031

差距很明顯，vector 快  回復(fù)  更多評論
  

@giscn
我用你的同樣的代碼在 VC6 和 VC9 上測試了一下,

VC6:
135140
12437

VC9:
162422
32766

差距也很明顯, 拙作強一點點. 當然, vc6 和 VC9 的 STL 和現(xiàn)在的 sgi STL 不具可比性, 樓上的愿意提供更好的解決方式嗎? 俺沒研讀過 sgi STL 的源代碼.
  回復(fù)  更多評論
  

VC6可以用 STLport
  回復(fù)  更多評論
  

@giscn
我的意思是您能否對我的實現(xiàn)代碼提供點建議  回復(fù)  更多評論
  

大致看了一下，做法其實都差不多，只能從更細微的地方分析了，你用的什么配置？這么慢？我是在AMD64 3000+ 測試的
  回復(fù)  更多評論
  

在VC6 下測試的結(jié)果是
2140
1938

我自己寫過一個vector的簡化版，居然是 500, 但是到VC9下面就比vector 慢一半  回復(fù)  更多評論
  

@giscn
我的計算機配置是 intel p-m 2.0G hz, 750 m 內(nèi)存.

奇怪的是, 獨立運行時, VC9 的結(jié)果是:
161203
430172

不解, 此前是在調(diào)試器上運行的 DEBUG 版本.   回復(fù)  更多評論
  

@giscn
我想問題出在 push_back 函數(shù)上, 俺沒有專門針對 push_back 函數(shù)做優(yōu)化, 而是為了代碼的簡潔, 直接重用了 insert 函數(shù)的調(diào)用, 拖慢了速度. 而我的應(yīng)用里插入操作其實不多. 所以我的應(yīng)用里的表現(xiàn)和上述測試程序的表現(xiàn)大相徑庭就正常了. 有空俺會改進的.   回復(fù)  更多評論
  

修改版提交, 最后的測試結(jié)果添加到文章的末尾了.  回復(fù)  更多評論
  

要考慮構(gòu)造與析構(gòu)，這是設(shè)計模板庫比較麻煩的地方，考慮的細節(jié)很多，嚴格來講，代碼是有問題的。

其他的，接口定義與STL vector 是有好處的, 當然這只是一個建議。
我覺得mem**** 函數(shù)是可以用的。  回復(fù)  更多評論
  

vector的速度沒有多少常規(guī)優(yōu)化的空間了。  回復(fù)  更多評論
  

這玩意兒只能放plain old data。
諸如ArrayDynamic < ArrayDynamic < int > >的好像就不行了。
看起來是這樣的。

我自己的做法是，模板提供了一個參數(shù)讓用戶自己選擇要plain old data還是處理所有類型的數(shù)據(jù)。雖然麻煩了點，不過效率就沒問題了。  回復(fù)  更多評論
  

@陳梓瀚(vczh)
樓上的, 俺一開始就說了, 就是想提升我的應(yīng)用的性能, 就是要處理 plain old data, 俺不想重復(fù)造輪子.   回復(fù)  更多評論
  

但是plain old data的表達能力跟你維護指針的痛苦程度是成正比的，所以才有非POD的東西。很不劃算。  回復(fù)  更多評論
  

@陳梓瀚(vczh)
給點建設(shè)性意見出來!!! 老是挑出一堆刺出來, 然后撒手不管; 這是解決問題的正確態(tài)度嗎?
  回復(fù)  更多評論
  

如果使用的是SGI STL或者STLPort，那么這種優(yōu)化意義不大，因為SGI STL的實現(xiàn)已經(jīng)考慮了對于POD的優(yōu)化（通過typetraits來判斷是否為POD，然后使用mem*函數(shù)） 。
提高vector性能可從兩方面考慮：
1）使用特定內(nèi)存池，實現(xiàn)一個Allocator, 利用vector 的第二個模板參數(shù)。這也是提高STL容器性能的常規(guī)辦法。
2）此處成為性能瓶頸，是不是系統(tǒng)設(shè)計方面有什么問題？可以從整個系統(tǒng)優(yōu)化的角度來考慮。  回復(fù)  更多評論
  

@eXile
謝謝提供思路. 我先比對標準組件和我的實現(xiàn)的性能, 再決定取舍. 順便一說, 我所在團隊開發(fā)的系統(tǒng)里的編譯器都是使用 VC7.1 編譯整個解決方案, 不使用 STLport 等第三方庫, 夠固步自封的. 而我的模塊必須要 HOOK 整個操作系統(tǒng)的關(guān)鍵繪圖函數(shù) Bitblt, 因此遭遇瓶頸.   回復(fù)  更多評論
  

7.1的stl 已經(jīng)不錯，好像不必折騰STLport  回復(fù)  更多評論
  

支持eXile同學的想法。
如果不考慮對c原生數(shù)組的支持，可以使用特定的內(nèi)存池來獲得性能的提升。
性能的損耗主要在拷貝構(gòu)造中。恰當使用內(nèi)存池可以避免這一點的頻繁發(fā)生。  回復(fù)  更多評論
  

動態(tài)數(shù)組確實快,vc2008
719
219   回復(fù)  更多評論