編註：這是gnu grep的原作者mike haertel 在freebsd
郵件列表中對 「gnu grep為什麼比bsd grep要快」 所做的回答，下面是郵件正文內容：
gabor 您好，
我是gnu grep的原作者，同時也是一名freebsd使用者，不過我一直使用的是-stable版本（也就是更老的版本），而沒怎麼關注-current版本。
但是，當我無意間翻閱-current版的郵件列表時，偶然發現了一些關於bsd grep與gnu grep效能的討論，你可能也注意到了那些討論。
#技巧1：gnu grep之所以快是因為它並不會去檢查輸入中的每乙個位元組。
#技巧2：gnu grep之所以快是因為它對那些的確需要檢查的每個位元組都執行非常少的指令（操作）。
gnu grep還展開了boyer-moore演算法的內部迴圈，並建立了乙個boyer-moore的delta表，這樣它就不需要在每乙個展開的步驟進行迴圈 退出判斷了。這樣的結果就是，在極限情況下（in the limit），gnu grep在需要檢查的每乙個輸入位元組上所執行的x86指令不會超過3條（並且還跳過了許多位元組）。
一旦有了快速搜尋，這時你會發現也需要同樣快速的輸入。
gnu grep使用了原生unix輸入系統呼叫並避免了在讀取後對資料進行拷貝。
而且，gnu grep還避免了對輸入進行分行，查詢換行符會讓grep減慢好幾倍，因為要找換行符你就必須檢視每個位元組！
所以gnu grep沒有使用基於行的輸入，而是將原資料讀入到乙個大的緩衝區buffer，用boyer-moore演算法對這個緩衝區進行搜尋，只有在發現乙個匹配之後才會去查詢最近的換行符（某些命令引數，比如-n會禁止這種優化）。
最後，當我還在維護gnu grep的時候（15+年前……），gnu grep也嘗試做一些非常困難的事情使核心也能避免處理輸入的每個位元組，比如使用mmap()而不是read()來進行檔案輸入。當時，用read()會 使大部分unix版本造成一些額外的拷貝。因為我已經不再gnu grep了，所以似乎mmap已經不再預設使用了，但是你仍然可以通過引數–mmap來啟用它，至少在檔案系統的buffer已經快取了你的資料的情況 下，mmap仍然要快一些：12
3456
78$timesh -c'find . -type f -print | xargs grep -l 123456789abcdef'
real 0m1.530s
user 0m0.230s
sys 0m1.357s
$timesh -c'find . -type f -print | xargs grep --mmap -l 123456789abcdef'
real 0m1.201s
user 0m0.330s
sys 0m0.929s
[這裡使用的輸入是乙個648m的mh郵件資料夾，包含大約41000條資訊]
所以即使在今天，使用–mmap仍然可以提速20%以上。
總結：
- 使用boyer-moore演算法（並且展開它的內層迴圈）。
- 使用原生系統呼叫來建立你的緩衝輸入，避免在搜尋之前拷貝輸入位元組。（無論如何，最好使用緩衝輸出，因為在grep的常用場景中，輸出的要比輸入的少，所以輸出緩衝拷貝的開銷要小，並且可以節省許多這樣小的無緩衝寫操作。）
- 在找到乙個匹配之前，不要查詢換行符。
- 嘗試做一些設定（比如頁面對齊緩衝區，按頁大小來讀取塊，選擇性的使用mmap），這樣可以使核心避免拷貝位元組。
讓程式變得更快的關鍵就是讓它們做更少的事情。;-)
致禮mike
雜湊表查詢為何如此之快
雜湊是在記錄的儲存位置和它的關鍵字之間建立乙個確定的對應關係f，使得每個關鍵字key對應乙個儲存位置f key 建立了關鍵字與儲存位置的對映關係，公式如下 設所有可能出現的關鍵字集合記為u 簡稱全集 實際發生 即實際儲存 的關鍵字集合記為k k 比 u 小得多 雜湊方法是使用函式f將u對映到表t 0...
HANA資料庫為何如此之快
原文標題是how sap hana is such a fast database，不過作者的觀點是hana的快主要源自硬體的發展，而且hana並非適合所有的應用場景。不過我關注的恰好是結論之外的部分。儲存硬體的提公升，從物理磁碟到ssd,記憶體，相應的資料庫查詢方式也發生了變化。當資料庫使用傳統的...
HANA資料庫為何如此之快
原文標題是how sap hana is such a fast database，不過作者的觀點是hana的快主要源自硬體的發展，而且hana並非適合所有的應用場景。不過我關注的恰好是結論之外的部分。儲存硬體的提公升，從物理磁碟到ssd,記憶體，相應的資料庫查詢方式也發生了變化。當資料庫使用傳統的...