太多的事情要做，却没有一件能够完成，至少没有一件能够稍微完美一些，如果完美也可以比较的话。
如此长的时间，我一直沉侵在一种沮丧的感觉中，无力感包围着我，眼看时间就那么轻易的从我的身边溜走，我像在做梦。意识清醒，清楚地知道身边的每一件事，你却无力去做些什么，哪怕一点改变？仿佛我已经是生活的观众，也许更像是服下了慢性毒药，一点点地却又不可阻挡的滑向深渊。
,----
| #include
| int STRLEN(char* p);
| int main()
| {
| char *str="Hello";
| int len=STRLEN(str);
| printf("%d\n",len);
| return 0;
| }
| int STRLEN(char *a)
| {
| return (*a)?STRLEN(a+1)+1:0;
| }
`----
这样的trick有什么意义？
我使用oprofile分别生成了bin/collect.exe和bin/format.exe的opreport
对于 collect.exe的日志分析，我发现主要在于
12105 17.7277 collect.exe SFC::SFCommunicationSocket::GetLine(std::string&)
11837 17.3352
collect.exe SFC::SFCommunicationSocket::Recv(void*, int) 这两个方法上， 总共占用了35％的cpu时间，也是耗费最多的两个方法。我想这是值得我们关注的东西，应该这是程序自己封装的，也许更有改变的可能。。。
继续看collect.exe 的日志文件
9908 14.5102 anon (tgid:9213 range:0xb7fbc000-0xb7fbd000) (no symbols)
9605 14.0665 anon (tgid:8943 range:0xb7f79000-0xb7f7a000) (no symbols)
5506 8.0635 collect.exe HandleUnixAndWindowsStyleList(char const*, struct_file_info&)
3167 4.6381 collect.exe
GetDir(struct_site_info&, std::string const&, SiteFile&, SFC::SFFTPClient*, unsigned short, bool)
这是耗费排在3-6位的四个函数，可以看到前六个函数的耗费在总耗费的3/4左右，所以我们也应该把主要精力放在这些函数上。其中两个anon我不是太清楚怎么回事，从网上的一些资料看到，好像表 示的是一块连续内存的操作，我猜测是mmap，xyb提到过他使用了mmap,我猜也许是 这里，我没有看源码，纯粹的猜测。。
再看format.exe的日志文件
18229 10.0997 format.exe MergeIndex(File&, File&, std::vector<unsigned int, std::allocator<unsigned int> >&, int)
这就是format.exe中cpu时间最长的函 数，format.exe有一个特点，就是cpu占用在0.01和0.1之间的函数特别多，不像 collect.exe那样有两个显著的寡头，这样有个不好的地方就是重点比较分散。我结合了valgrind的callgrind产生的日志看了一下，大概是IndexDB和FileDB两个类中的CreateIndex Update比较耗费时间，应该引起注意上边是我对日志文件的一些 分析，基本没有接触源代码，现在我想说我看到的一个和源码有关的问题 ,
1 #include <stdio.h>
2 #include <ctype.h>
3
4 int alpha1(char c);
5 int alpha2(char c);
6 int main()
7 {
8 char c='M';
9 long int i;
10 for(i=0;i<6553500;i++)
11 {
12 alpha1(c);
13 alpha2(c);
14 }
15
16 return 0;
17 }
18 int alpha1(char c)
19 {
20 if(c >= 'A' && c <='Z')
21 printf("OK\n");
22 return 0;
23 }
24 int alpha2(char c)
25 {
26 if(isupper(c))
27 printf("OK\n");
28 return 0;
29 }
