注意线程安全啊  回复  更多评论
  

@水
这个知道, 谁使用谁负责线程间数据一致性, 我这个主要负责提高性能, 同一进程内可以使用临界区, 互斥量, 信号量等等. 不同进程使用互斥量, 信号量等, 推荐使用信号量.
  回复  更多评论
  

你这个实现快了多少呢？能分析一下为什么会快吗？  回复  更多评论
  

在我的项目里, 至少提高了 3 倍以上, 当然没有具体的测试数据, 只是目测. 你有兴趣可以试试. 呵呵. 当然, 还有其他的改进, 比如, 将内核级的信号量改成用临界区, 因为只有进程内部共享数据. 无进程间通讯的需求.  回复  更多评论
  

1、快在哪？
2、如果T重载了operator =，那insert里的*(m_pArray+nPos)=element;是非常危险的；
3、模板类应该慎用mem*系列函数；
4、……
  回复  更多评论
  

"sage_ulti"
这个是不是"sage_util"？  回复  更多评论
  

@土
第一, 我仅仅是让我的工作高效的完成. 而设计一个简单的类, 不是要设计一个工业强度的库.
第二, 危险不危险各人心中有数. 崩掉了自己会找到原因的.
第三, 交流心得就交流心得, 你觉得你高明自个儿写文章去, 这里不容纳你的排泄物.   回复  更多评论
  

@木
毫无意义, 你可以将这个名字空间换成你的, 甚至将其完全删除  回复  更多评论
  

这回复貌似是一个人 金木水火土都要快齐了  回复  更多评论
  

不错.....不过同一进程内可以使用临界区, 互斥量, 信号量等等. 不同进程使用互斥量, 信号量等, 推荐使用信号量. ??

是什么意思啊??
可以说明白吗?为什么在线程时要这样呢??不太明白,希望可以讲下..谢谢!  回复  更多评论
  

@RichardHe
多线程同步的问题, 建议找本侯捷翻译的《Win32多线程程序设计》书看看, 里面有你想要的.
  回复  更多评论
  

不要和 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  回复  更多评论
  

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

1078
3031

差距很明显，vector 快  回复  更多评论
  

@giscn
我用你的同样的代码在 VC6 和 VC9 上测试了一下,

VC6:
135140
12437

VC9:
162422
32766

差距也很明显, 拙作强一点点. 当然, vc6 和 VC9 的 STL 和现在的 sgi STL 不具可比性, 楼上的愿意提供更好的解决方式吗? 俺没研读过 sgi STL 的源代码.
  回复  更多评论
  

VC6可以用 STLport
  回复  更多评论
  

@giscn
我的意思是您能否对我的实现代码提供点建议  回复  更多评论
  

大致看了一下，做法其实都差不多，只能从更细微的地方分析了，你用的什么配置？这么慢？我是在AMD64 3000+ 测试的
  回复  更多评论
  

在VC6 下测试的结果是
2140
1938

我自己写过一个vector的简化版，居然是 500, 但是到VC9下面就比vector 慢一半  回复  更多评论
  

@giscn
我的计算机配置是 intel p-m 2.0G hz, 750 m 内存.

奇怪的是, 独立运行时, VC9 的结果是:
161203
430172

不解, 此前是在调试器上运行的 DEBUG 版本.   回复  更多评论
  

@giscn
我想问题出在 push_back 函数上, 俺没有专门针对 push_back 函数做优化, 而是为了代码的简洁, 直接重用了 insert 函数的调用, 拖慢了速度. 而我的应用里插入操作其实不多. 所以我的应用里的表现和上述测试程序的表现大相径庭就正常了. 有空俺会改进的.   回复  更多评论
  

修改版提交, 最后的测试结果添加到文章的末尾了.  回复  更多评论
  

要考虑构造与析构，这是设计模板库比较麻烦的地方，考虑的细节很多，严格来讲，代码是有问题的。

其他的，接口定义与STL vector 是有好处的, 当然这只是一个建议。
我觉得mem**** 函数是可以用的。  回复  更多评论
  

vector的速度没有多少常规优化的空间了。  回复  更多评论
  

这玩意儿只能放plain old data。
诸如ArrayDynamic < ArrayDynamic < int > >的好像就不行了。
看起来是这样的。

我自己的做法是，模板提供了一个参数让用户自己选择要plain old data还是处理所有类型的数据。虽然麻烦了点，不过效率就没问题了。  回复  更多评论
  

@陈梓瀚(vczh)
楼上的, 俺一开始就说了, 就是想提升我的应用的性能, 就是要处理 plain old data, 俺不想重复造轮子.   回复  更多评论
  

但是plain old data的表达能力跟你维护指针的痛苦程度是成正比的，所以才有非POD的东西。很不划算。  回复  更多评论
  

@陈梓瀚(vczh)
给点建设性意见出来!!! 老是挑出一堆刺出来, 然后撒手不管; 这是解决问题的正确态度吗?
  回复  更多评论
  

如果使用的是SGI STL或者STLPort，那么这种优化意义不大，因为SGI STL的实现已经考虑了对于POD的优化（通过typetraits来判断是否为POD，然后使用mem*函数） 。
提高vector性能可从两方面考虑：
1）使用特定内存池，实现一个Allocator, 利用vector 的第二个模板参数。这也是提高STL容器性能的常规办法。
2）此处成为性能瓶颈，是不是系统设计方面有什么问题？可以从整个系统优化的角度来考虑。  回复  更多评论
  

@eXile
谢谢提供思路. 我先比对标准组件和我的实现的性能, 再决定取舍. 顺便一说, 我所在团队开发的系统里的编译器都是使用 VC7.1 编译整个解决方案, 不使用 STLport 等第三方库, 够固步自封的. 而我的模块必须要 HOOK 整个操作系统的关键绘图函数 Bitblt, 因此遭遇瓶颈.   回复  更多评论
  

7.1的stl 已经不错，好像不必折腾STLport  回复  更多评论
  

支持eXile同学的想法。
如果不考虑对c原生数组的支持，可以使用特定的内存池来获得性能的提升。
性能的损耗主要在拷贝构造中。恰当使用内存池可以避免这一点的频繁发生。  回复  更多评论
  

动态数组确实快,vc2008
719
219   回复  更多评论