模擬2個使用者同時登陸乙個4核心處理器的電腦進行android編譯，編譯選項make -j8，cpu配置如下：
bhsong@sha-it-lintester01:~/workspace/android/kernel$cat /proc/cpuinfo processor :0 vendor_id :genuineintel cpu family :6 model :37 model name :intel(r) core(tm) i3 cpu 550 @ 3.20ghz processor :1 vendor_id :genuineintel cpu family :6 model :37 model name :intel(r) core(tm) i3 cpu 550 @ 3.20ghz processor :2 vendor_id :genuineintel cpu family :6 model :37 model name :intel(r) core(tm) i3 cpu 550 @ 3.20ghz processor :3 vendor_id :genuineintel cpu family :6 model :37 model name :intel(r) core(tm) i3 cpu 550 @ 3.20ghz
如果模擬
2個使用者同時登入伺服器並且同時編譯
android
，我們分析一下
cpu和磁碟利用率，如下圖：
我們可以看出cpu的利用率保持在100%幾乎不動（絕大多數時間在userspace運算而非進入kernel系統呼叫），而磁碟的佔用率依然非常低，不超過10%。
基本可以看出由於受限於編譯過程中等待cpu和makefile的同步，android編譯過程中對io的需求不大（或者此案例無法發揮），基本在1mb以內或者1mb左右徘徊。
到編譯的後期階段，主要工作變成了將編譯結果拷貝到out目錄，則呈現出io需要增大的趨勢，不過到install階段，cpu利用率依然很高：
另外，也考察了一下記憶體的情況，這個編譯電腦的記憶體是12g左右，2個使用者編譯幾乎沒有達到滿載，看到的高峰時段如下：
bhsong@sha-it-lintester01:/proc$ free total used free shared buffers cached mem: 12255168 11840396 414772 0 654472 5788252 -/+ buffers/cache: 5397672 6857496 swap: 4050940 5256 4045684我們看到swap的使用情況很低，意味著記憶體尚為成為瓶頸要求磁碟虛擬記憶體，高峰時段free的memory一直都存在（高峰時段還剩下400mb），其中耗掉的記憶體中有多達6gb左右也是做檔案系統cache用在，實際hold住的記憶體大概5.5gb。
由此，對於android編譯而言，選擇高檔cpu如16核心是重要需求，io和記憶體不是主要的瓶頸。
android編譯時拷貝檔案及資料夾
拷貝檔案 拷貝資料夾 product copy files call find copy subdir files,local path system vendor 或者 shell mkdir p system etc 原始碼編譯的時候，先讀取該mk檔案，該目錄還沒建立，所以要建乙個，否則拷貝失敗...
編譯原理 LR分析（主要是LR（0）分析）
lr方法的基本思想就是，在規範歸約的過程中，一方面要記住已移進和歸約出的整個字串，也就是說要記住歷史 一方面能夠根據所用的產生式的推測未來可能碰到的輸入符號，也就是說能夠對未來進行展望。這樣，當一串貌似控制代碼的字串出現在分析棧的頂部時，我們希望能夠根據歷史和展望以及現實的輸入符號這三部分的材料，決...
編譯原理 LR分析（主要是LR（0）分析）
lr方法的基本思想就是，在規範歸約的過程中，一方面要記住已移進和歸約出的整個字串，也就是說要記住歷史 一方面能夠根據所用的產生式的推測未來可能碰到的輸入符號，也就是說能夠對未來進行展望。這樣，當一串貌似控制代碼的字串出現在分析棧的頂部時，我們希望能夠根據歷史和展望以及現實的輸入符號這三部分的材料，決...