最近在做一个性能要求较高的项目,有个服务器需要处理每秒2万个udp包,每个包内有40个元素(当然这是高峰期)。服务器需要一个链表,算法中有个逻辑要把每个元素添加到链表末尾(只是这个元素对象的指针,不存在对象复制的问题),再从链表中把这些元素取出(另一个时间点)。就是一个单线程在做这件事。
既然逻辑这么简单,我自然选用了C++的标准STL容器List(Linux GNU),想来如此简单的事情,不过是一次末尾插入,一次头部取出而已,就用STL的List容器吧。没有想到这是痛苦的开始。我预想中每秒处理80万元素应该是很轻松写意的,没想到每秒一千个包时服务器就顶不住了,处理算法的线程占用CPU达到百分之百,大量的包得不到及时处理而超时。由于算法较为复杂,定位这问题耗了不少时间,终于感觉到LIST容器似乎有严重性能问题。
于是干脆自己写了个简单的链表,替代了STL的容器后性能有了极大的提升。为此我特意写了个简单的程序,大致模仿我算法中的场景,程序流程如下:
每3秒中向链表中插入N个元素(指针),再把这N个元素从链表中取出释放。之后查看耗时t,如果t小于3秒,就sleep(3-t)秒,并打印出睡眠的时间。
在我的测试机上,出现了差异很大的测试结果,大约每3秒测试2万个元素时,使用STL LIST的压力程序导致CPU已经达到70%了,而使用自己写的简单链表几乎没有感觉。直到每3秒测试2000万个元素时,才导致CPU占用80%。结果有一千倍的差距!这里没有对象的复制,我插入链表的都只是指针而已!(下面附测试程序,这里只是对比两种list的性能,所以我想机器的参数并不重要,大家随意找台Linux机器用下述代码执行下就可对比出。)
#include <list>
#include <sys/time.h>
#include <iostream>
using namespace std;
//待测试的对象,链表中的每个元素就是对象A的指针
class A {};
//每3秒钟插入链表末尾/从链表首部取出的元素个数
int testPressureNum = 40000;
//测试的STL链表
list<A*> testList;
//自己写的链表
typedef struct
{
A* p;
void* prev;
void* next;
} SelfListElement;
SelfListElement* myListHead;
SelfListElement* myListTail;
int myListSize;
//向自己写的链表首部添加元素
bool add(A* packet)
{
SelfListElement* ele = new SelfListElement;
ele->p = packet;
myListSize++;
if (myListHead == NULL)
{
myListHead = myListTail = ele;
ele->prev = NULL;
ele->next = NULL;
return true;
}
ele->next = myListHead;
myListHead->prev = ele;
ele->prev = NULL;
myListHead = ele;
return true;
}
// 从自己写的链表尾部取出元素
SelfListElement* get()
{
if (myListTail == NULL)
return NULL;
myListSize--;
SelfListElement* p = myListTail;
if (myListTail->prev == NULL)
{
myListHead = myListTail = NULL;
}
else
{
myListTail = (SelfListElement*)myListTail->prev;
myListTail->next = NULL;
}
return p;
}
//从STL链表中取出元素并删除
void testDelete1()
{
while (testList.size() > 0)
{
A* p = testList.back();
testList.pop_back();
delete p;
p = NULL;
}
}
//从简单链表中取出元素并删除
void testDelete2()
{
do {
SelfListElement* packet = myListTail;
if (packet == NULL)
break;
packet = get();
delete packet->p;
delete packet;
packet = NULL;
} while (true);
}
//向Stl链表中添加元素
void testAdd1()
{
for (int i = 0; i < testPressureNum; i++)
{
A* p = new A();
testList.push_front(p);
}
}
//向简单链表中添加元素
void testAdd2()
{
for (int i = 0; i < testPressureNum; i++)
{
A* p = new A();
add(p);
}
}
void printUsage(int argc, char**argv)
{
cout<<"usage: "<<argv[0]<<" [1|2] [oneRoundPressueNum]"<<endl
<<"1 means STL, 2 means simple list\noneRoundPressueNum means in 3 seconds how many elements add/del in list"<<endl;
}
int main(int argc, char** argv)
{
//为方便测试可使用2个参数
if (argc < 2)
{
printUsage(argc, argv);
return -1;
}
int type = atoi(argv[1]);
if (type != 1 && type != 2)
{
printUsage(argc, argv);
return -2;
}
if (argc >= 2)
testPressureNum = atoi(argv[2]);
cout<<"every 3 seconds add/del element number is "<<testPressureNum<<endl;
struct timeval time1, time2;
gettimeofday(&time1, NULL);
while (true)
{
gettimeofday(&time1, NULL);
if (type == 1)
{
testAdd1();
cout<<"stl list has "<<testList.size()<<" elements"<<endl;
}
else
{
testAdd2();
cout<<"my list has "<<myListSize<<" elements"<<endl;
}
//每3秒一个周期
gettimeofday(&time2, NULL);
unsigned long interval = 1000000*(time2.tv_sec-time1.tv_sec)+
time2.tv_usec-time1.tv_usec;
if (interval < 3000000)
{
cout<<"after add sleep "<<3000000-interval<<" usec"<<endl;
usleep(3000000-interval);
}
else
cout<<"add cost time too much"<<interval<<endl;
gettimeofday(&time1, NULL);
if (type == 1)
{
testDelete1();
cout<<"stl list has "<<testList.size()<<" elements"<<endl;
}
else
{
testDelete2();
cout<<"my list has "<<myListSize<<" elements"<<endl;
}
//每3秒一个周期
gettimeofday(&time2, NULL);
interval = 1000000*(time2.tv_sec-time1.tv_sec)+
time2.tv_usec-time1.tv_usec;
if (interval < 3000000)
{
cout<<"after delete sleep "<<3000000-interval<<" usec"<<endl;
usleep(3000000-interval);
}
else
cout<<"delete cost time too much"<<interval<<endl;
}
return 0;
}
一千倍的性能差距太夸张了。究竟是什么原因导致STL性能这么差呢?修改上面的测试代码,分别在testAdd和 testDelete中加时间点,结果发现,自己写的插入删除耗时相差不大,然而STL就差距极大了,下面列下我机器上测试得到的结果。
使用STL LIST的结果:
[root@AT-HOUYIDEV-AG]$./test 1 30000
every 3 seconds add/del element number is 30000
stl list has 30000 elements
after add sleep 2993282 usec
stl list has 0 elements
delete cost time too much3290628
stl list has 30000 elements
after add sleep 2996936 usec
stl list has 0 elements
delete cost time too much3273876
使用自写LIST的结果:
[root@AT-HOUYIDEV-AG]$./test 2 20000000
every 3 seconds add/del element number is 20000000
my list has 20000000 elements
after add sleep 1222930 usec
my list has 0 elements
after delete sleep 2187505 usec
my list has 20000000 elements
after add sleep 2064313 usec
my list has 0 elements
after delete sleep 2187214 usec
可以看到,
STL最大问题在于删除,LIST的插入还是算快的,但是删除就非常之慢了。测试同样多的元素时,两者消耗的内存也是相近的!为什么CPU消耗差这么多呢?
随便下了个sgi STL 3.3的源码,可以看到从LIST头尾删除元素的方法最终都是调用erase方法:
void pop_front() { erase(begin()); }
void pop_back() {
iterator __tmp = end();
erase(--__tmp);
}
那么erase又干了些什么呢?
iterator erase(iterator __position) {
_List_node_base* __next_node = __position._M_node->_M_next;
_List_node_base* __prev_node = __position._M_node->_M_prev;
_Node* __n = (_Node*) __position._M_node;
__prev_node->_M_next = __next_node;
__next_node->_M_prev = __prev_node;
_Destroy(&__n->_M_data);
_M_put_node(__n);
return iterator((_Node*) __next_node);
}
看来耗CPU确实是因为LIST在删除元素时做了太多事,特别是为迭代器做了太多事!我仅仅只是从链表中删除一个8字节的指针而已,就消耗了这么多的CPU!如果不编写服务器,或者服务器性能要求不高,到是可以用STL的LIST,否则,真是得不偿失啊!如果只是简单需要LIST的功能,还是自己写个吧,层层封装的STL试图使程序员使用简单,试图满足最广泛的程序员,但性能确实很糟糕!
为什么插入相对快很多呢?两个插入头尾的方法如下:
void push_front(const _Tp& __x) { insert(begin(), __x); }
void push_front() {insert(begin());}
void push_back(const _Tp& __x) { insert(end(), __x); }
void push_back() {insert(end());}
其中insert方法是这样的:
iterator insert(iterator __position, const _Tp& __x) {
_Node* __tmp = _M_create_node(__x);
__tmp->_M_next = __position._M_node;
__tmp->_M_prev = __position._M_node->_M_prev;
__position._M_node->_M_prev->_M_next = __tmp;
__position._M_node->_M_prev = __tmp;
return __tmp;
}
插入时只是简单分配了个Node,并没有做迭代器的修改。
分享到:
相关推荐
c语言坑爹大冒险-C 语言基础
《少儿编程Scratch项目:坑爹小游戏》 Scratch,由麻省理工学院(MIT)媒体实验室“终身幼儿园”团队开发,是一款专为儿童设计的编程语言和视觉化编程工具,旨在培养孩子的逻辑思维能力、创新能力和问题解决能力。这...
《坑爹游戏2》是一款专为少儿设计的编程学习项目,使用了流行的Scratch编程语言。Scratch是由麻省理工学院(MIT)的“终身幼儿园团队”开发的一款面向儿童的图形化编程工具,旨在帮助孩子们通过拖拽积木式的编程块来...
《坑爹游戏3》是一款专为少儿设计的编程学习项目,使用了流行的Scratch编程语言。这个项目旨在通过趣味性的游戏开发,激发孩子们对编程的兴趣,同时培养他们的逻辑思维能力和解决问题的能力。Scratch是由麻省理工...
Redux DevTools 是一款强大的调试工具,用于优化和理解 Redux 应用的状态管理。这个工具提供了一种可视化的方式来追踪你的 Redux 应用中的状态变化和动作流,帮助开发者更好地调试和优化代码。本指南将介绍如何在 ...
标题中的“适用于麒麟的kibana-那是相当的坑爹-好不容易找到的一个能用的-祖传级别”表明这是一个针对麒麟操作系统的定制版Kibana,由于在适配过程中遇到了诸多困难,所以被形容为“坑爹”,同时强调了其稀缺性和...
java坑爹的笔试题 没有最坑,只有更坑! 活动简介 作为一个程序员,你看过哪些坑爹代码,你又写过多少坑爹代码,还有多少你不知道的坑爹代码?本仓库的目的就是为了收集这些坑爹代码,可以让别人不掉坑或者少掉坑,...
6--[坑爹小游戏].zip源码scratch2.0 3.0编程项目源文件源码案例素材源代码6--[坑爹小游戏].zip源码scratch2.0 3.0编程项目源文件源码案例素材源代码6--[坑爹小游戏].zip源码scratch2.0 3.0编程项目源文件源码案例...
除此之外,文件操作也可能在"坑爹大冒险"中扮演角色。游戏可能需要保存玩家进度或者读取预设的游戏地图和剧情,这就需要用到fopen()、fwrite()、fread()、fclose()等文件操作函数。 在项目中,"资源说明.txt"文件...
《易语言编写的坑爹记事本》是一款由易语言编程开发的简易记事本程序。易语言,作为中国本土的编程语言,以其简洁的语法和面向初学者的设计,为许多编程爱好者提供了学习编程的入口。然而,"坑爹记事本"这个称号可能...
本文将深入探讨C语言中的若干常见陷阱,帮助你更好地理解和避免这些"坑爹"的情况。 1. **类型转换陷阱**: 在C语言中,不同类型之间的转换如果不谨慎,很容易造成数据丢失或意外的行为。例如,将一个较大的整型值...
61--[坑爹游戏2].zip源码scratch2.0 3.0编程项目源文件源码案例素材源代码61--[坑爹游戏2].zip源码scratch2.0 3.0编程项目源文件源码案例素材源代码61--[坑爹游戏2].zip源码scratch2.0 3.0编程项目源文件源码案例...
60--[坑爹游戏3].zip源码scratch2.0 3.0编程项目源文件源码案例素材源代码60--[坑爹游戏3].zip源码scratch2.0 3.0编程项目源文件源码案例素材源代码60--[坑爹游戏3].zip源码scratch2.0 3.0编程项目源文件源码案例...
java坑爹的笔试题 cpp-primer-5th C++ Primer第五版学习资料 C++Primer第五版——习题答案+详解(完整版) 作者学习心得 2017年3月23日更新:历时三个月,粗略的算是看完了这本书,简单的进行总结一下: 本书的Part I...
c语言坑爹大冒险完整源码 c语言坑爹大冒险完整源码 c语言坑爹大冒险完整源码 c语言坑爹大冒险完整源码 c语言坑爹大冒险完整源码 c语言坑爹大冒险完整源码 c语言坑爹大冒险完整源码 c语言坑爹大冒险完整源码 c语言...
毕设-c语言坑爹大冒险5
《史上最坑爹的游戏6》是由珠海顶峰互动科技研发的一款休闲益智类解谜游戏,简称“坑爹游戏”,于2013年发行。《史上最坑爹的游戏》是一个让人抓狂、让人迷恋、让人傻笑的游戏。 其中设计了大量奇思妙想,趣味连篇的...
"坑爹大冒险(C语言).zip" 这个压缩包文件看起来是一个与C语言编程相关的项目,可能是一个小型游戏或教学示例。通过它的标题,我们可以推测它包含了一些设计巧妙、富有挑战性的编程练习或者游戏关卡,旨在帮助学习...
"C语言坑爹大冒险"这个标题或许是以一种幽默的方式指出了初学者在学习C语言过程中可能会遇到的各种挑战和陷阱。这些挑战可能包括语法错误、内存管理问题、指针操作不当以及对标准库函数的不熟悉等。 1. **基础知识*...