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

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

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

在我的項目里, 至少提高了 3 倍以上, 當(dāng)然沒有具體的測試數(shù)據(jù), 只是目測. 你有興趣可以試試. 呵呵. 當(dāng)然, 還有其他的改進(jìn), 比如, 將內(nèi)核級的信號量改成用臨界區(qū), 因為只有進(jìn)程內(nèi)部共享數(shù)據(jù). 無進(jìn)程間通訊的需求.  回復(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è)強(qiáng)度的庫.
第二, 危險不危險各人心中有數(shù). 崩掉了自己會找到原因的.
第三, 交流心得就交流心得, 你覺得你高明自個兒寫文章去, 這里不容納你的排泄物.   回復(fù)  更多評論
  

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

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

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

是什么意思啊??
可以說明白嗎?為什么在線程時要這樣呢??不太明白,希望可以講下..謝謝!  回復(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

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

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

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

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

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

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

@giscn
我的計算機(jī)配置是 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)大相徑庭就正常了. 有空俺會改進(jìn)的.   回復(fù)  更多評論
  

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

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

其他的，接口定義與STL vector 是有好處的, 當(dāng)然這只是一個建議。
我覺得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的表達(dá)能力跟你維護(hù)指針的痛苦程度是成正比的，所以才有非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
謝謝提供思路. 我先比對標(biāo)準(zhǔn)組件和我的實現(xiàn)的性能, 再決定取舍. 順便一說, 我所在團(tuán)隊開發(fā)的系統(tǒng)里的編譯器都是使用 VC7.1 編譯整個解決方案, 不使用 STLport 等第三方庫, 夠固步自封的. 而我的模塊必須要 HOOK 整個操作系統(tǒng)的關(guān)鍵繪圖函數(shù) Bitblt, 因此遭遇瓶頸.   回復(fù)  更多評論
  

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

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

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