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

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

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

在我的項(xiàng)目里, 至少提高了 3 倍以上, 當(dāng)然沒(méi)有具體的測(cè)試數(shù)據(jù), 只是目測(cè). 你有興趣可以試試. 呵呵. 當(dāng)然, 還有其他的改進(jìn), 比如, 將內(nèi)核級(jí)的信號(hào)量改成用臨界區(qū), 因?yàn)橹挥羞M(jìn)程內(nèi)部共享數(shù)據(jù). 無(wú)進(jìn)程間通訊的需求.  回復(fù)  更多評(píng)論
  

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

"sage_ulti"
這個(gè)是不是"sage_util"？  回復(fù)  更多評(píng)論
  

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

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

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

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

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

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

不要和 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ù)  更多評(píng)論
  

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

1078
3031

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

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

VC6:
135140
12437

VC9:
162422
32766

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

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

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

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

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

我自己寫過(guò)一個(gè)vector的簡(jiǎn)化版，居然是 500, 但是到VC9下面就比vector 慢一半  回復(fù)  更多評(píng)論
  

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

奇怪的是, 獨(dú)立運(yùn)行時(shí), VC9 的結(jié)果是:
161203
430172

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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