程式效率的問題

---------------------------------------------------------

轉載

Author   : penny
WebSite  : http://blog.csdn.net/pennyliang

---------------------------------------------------------

for(;;)
   {
      void* buffer = malloc(SIZE); 
      memset(buffer,SIZE);
      process(buffer)
      free buffer;
   }   

   這是一位實習生（我曾帶過10+位實習生，因此見多識廣）的虛擬碼，原本這個SIZE很小，估計是存放URL用的，定義為512位元組，後來由於某種原因，擴大到了1M，從512位元組擴大到了1M，速度變慢很多。為什麼呢？這位同學無法解釋，但我讓他繼續探索，找到真正的原因。

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

   （1）首先分析一些主要花費時間的代碼，結果發現是memset這一段從512到1M後耗費時間增多，而且增多並不是線性，我讓他先看一下glibc的memset原始碼，如下：

#if defined _LIBC || defined STDC_HEADERS || defined USG
# include <string.h>
# 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是每位元組每位元組的賦值的，這並不是機器喜歡的方式，機器希望的是在4位元組對齊的位置上進行操作（32位機器，64位機器喜歡8位元組對齊），一次讀取32位（4個位元組）。因此memset完全可以自己實現一個一次性寫4個位元組的代碼。

   

 （2)接下來需要探索的是malloc，事實上linux記憶體配置有兩種，brk，mmap，前者分配128k以內的記憶體，後者分配128k以上的記憶體，在改成1M後，
       void* buffer = malloc(SIZE);
     這一段是很快的，因為只是分配了虛存，並沒有載入記憶體，可以查看/proc/pid/statm，考察記憶體配置，memset操作前後的變化。
      而memset，就需要進行實際的記憶體配置，缺頁中斷，載入TLB等等。
      而brk分配的記憶體是glibc管理的記憶體，分配很快，釋放也方便（很多時候其實並不釋放）。因此512位元組是，使用的brk分配（效率很高），而變成1M後，使用mmap分配（加上memset的低效）因此效率要低很多。 

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

    void* buffer = malloc(SIZE);  
    for(;;)
      {
         memset(buffer,SIZE);
         process(buffer)
     } 

     free buffer;

    

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

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