for(;;)

{

void* buffer = malloc(SIZE);

memset(buffer,SIZE);

process(buffer)

free buffer;

}

這是一位實習生(我曾帶過10+位實習生，因此見多識廣)的偽代碼，原本這個SIZE很小，估計是存放URL用的，定義為512字節(jié)，后來由于某種原因，擴大到了1M，從512字節(jié)擴大到了1M，速度變慢很多。為什么呢?這位同學無法解釋，但我讓他繼續(xù)探索，找到真正的原因。

我讓他從這樣幾個方面入手，

(1)首先分析一些主要花費時間的代碼，結果發(fā)現是memset這一段從512到1M后耗費時間增多，而且增多并不是線性的，我讓他先看一下glibc的memset源代碼，如下：

#if defined _LIBC || defined STDC_HEADERS || defined USG

# include

# define flood memset

#else

static void flood (__ptr_t, int, __malloc_size_t);

static void

flood (ptr, val, size)

__ptr_t ptr;

int val;

__malloc_size_t size;

{

char *cp = ptr;

while (size--)

*cp++ = val;

}

#endif

由此可知memset是每字節(jié)每字節(jié)的賦值的，這并不是機器喜歡的方式，機器希望的是在4字節(jié)對齊的位置上進行操作(32位機器，64位機器喜歡8字節(jié)對齊)，一次讀取32位(4個字節(jié))。因此memset完全可以自己實現一個一次性寫4個字節(jié)的代碼。

(2)接下來需要探索的是malloc，事實上linux內存分配有兩種，brk，mmap，前者分配128k以內的內存，后者分配128k以上的內存，在改成1M后，

void* buffer = malloc(SIZE);

這一段是很快的，因為只是分配了虛存，并沒有載入內存，可以查看/proc/pid/statm，考察內存分配，memset操作前后的變化。

而memset，就需要進行實際的內存分配，缺頁中斷，加載TLB等等。

而brk分配的內存是glibc管理的內存，分配很快，釋放也方便(很多時候其實并不釋放)。因此512字節(jié)是，使用的brk分配(效率很高)，而變成1M后，使用mmap分配(加上memset的低效)因此效率要低很多。

(3) 這段代碼如果改成，效果等價性能也會大幅度提升。

void* buffer = malloc(SIZE);

for(;;)

{

memset(buffer,SIZE);

process(buffer)

}

free buffer;

(4)最后需要質疑的是為什么需要開辟1M大小的空間，是否通過了驗證，這樣做是否有必要，實際情況是怎樣的，memset是否需要，是否可以通過什么其他方法來避免這種計算。

由此可見，很多問題，不好的編碼習慣，對機器理解的不夠透徹是很難再一般的工作中發(fā)現，必須在大規(guī)模數據處理的實踐場合(處理數據量足夠大)，才能體現出來，因此大規(guī)模數據處理技術是軟件、硬件相結合的技術，而且不僅僅是技術上的問題還包括了業(yè)務上的問題，廢代碼，廢計算應該去掉，不合理的計算應該變得合理。