[問題] compile 時間超過半小時

[tropical72 (藍影)]

事情整體經過大致如連結所述 http://ppt.cc/k7T-
目前手邊專案已接近尾聲，
想請教若日後遇到類似問題是否可避開。

開發平台(Platform): (Ex: VC++, GCC, Linux, ...) 
Visual C++ 2008 / 2010

問題(Question)：

事情經過是這樣的，有份 project 用了 excel 寫了近 5000 個公式 (5000個儲存格)，
這 5000 個公式都參照其中之 6*24 儲存格，由於時間有限及一些因素，
故用了偷吃步的方式，先讀入 x[6][24] ，再將每個 x[i][j] 定義成一 macro，
最後直接把 excel 上之公式顯示出來，以額外的 project 去生成所需程式碼。

這裡有做初步改善之方式為，將額外生成之程式碼分開成 lazy.c 進行獨立編譯，
生成一 lazy.obj，這樣要產生完整程式碼就不用重頭編譯，(指令也只能自己下了..)
只是在 lazy.c 和需求者協議後，還是改了四次，且每次編譯時間都愈來愈長，
最後自動產生的 lazy.c 行數長達 11000 行左右，於是在第四次編譯時，
花了近半小時時間才編譯完成，當然編出來的執行檔效能不會有太大差別。

目前自己推可能是定義了6*24 = 144 個 macro，
且 5000 個公式最後都掛上 macro 表示，還必須判斷分母不能為 0 (不然會死當)，
故才拖到半小時。

不知是否有類似經驗之先進，能提示是否有其他解決方案？
或，編譯半小時只是小事而已？
謝謝各位不吝回覆，感激不盡。

---

附一下我所說的部份

#define A1 x[0][0] // x[0][0] 對應到儲存格 A1
#define A2 x[1][0] // x[1][0] 對應到儲存格 A2
/* 一直定義到 x[5][23], 共 6*24 = 144 個 macro */

if( B1+C1 == 0.0) fprintf(fp,"-,");
else fprintf(fp, "%.2lf,", (B1)/(B1+C1));
/* 上面這二行是沒規則的公式, 直接寫另一個程式從 excel 抓下來處理 */
/* 共計有近 5000 個這種東西, 且使用之 macro 量不定 */

--
世界上有種，
將 不可能 轉換為 無限可能 的強大力量，
我稱它為 - 信念。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 180.177.76.201
→ chengcti:小事,買四核心就解決,以前我make手機要花 2hrs
→ chengcti:結案才是重點,我猜太多 array
→ gkk886:看不太懂 lazy.c不能再依式子拆開 編譯的時後平行化嗎?
便是因公式繁多，要了解原理、歸納出公式，倒不如硬暴較符合急件需求。
較想請教的是，編譯平行化之需求

推 ericinttu:假如經常遇到要花時間compile的話,單主機用i7 或是多台
→ ericinttu:主機聯手compile, 會比較省點事.
推 littleshan:半小時是小事，整個過程的自動化比較重要
自動化，執行效能、結果、顯示，對方都算滿意。
看完推文後的心得: 我以為 Athlon II X2 245 2.92G Hz 算不錯了, 看來是我有所誤解。

在此先謝謝樓上各位給予意見，可能第一次遇到費這麼久的，所以有點傻眼。

推 joefaq:http://ppt.cc/9,EX 參考一下
→ chengcti:難怪,我用i5跑了兩年.build一直都很快,換台i5吧.
→ chengcti:RAM加大,硬碟加大,工具自己會最佳化.
推 tomap41017:推樓上，換i5 + SSD才是王道..
推 irh:查一下.h是否有循環include的情況，機器只是隱藏了不良的習慣
→ james732:編譯工作對於IO的需求應該比較高，CPU幫助有限，衝SSD吧
推 littleshan:no,編譯工作是 computation intensive
@irh : 確定沒循環 include.

 後來借用了另一台備配
 程式是在RAMDISK 上生成， 記憶體 16GB， 2400MHz 記憶體 CL 9
 CPU 3770K@4.6g Memory 16G CL9 HDD RAMDISK ，
 18 分鐘 Orz..

我在想瓶頸是卡在 5000 個 if-else ，還是 144 個 macro ?
還是 5000 個 if-else + 144 個 macro XD

問題可能有到牛角地步，是很好奇到底為什麼會變這樣而已..
( 雖只是小事, 但難免會好奇..)
※ 編輯: tropical72      來自: 180.177.76.201       (12/31 01:41)
→ tinlans:編譯工作既吃 CPU 也吃 I/O，因為我都用 Gentoo 和
→ tinlans:FreeBSD，所有套件都是編譯安裝的，所以非常清楚。
→ tinlans:只是 CPU 的比重還是遠高於 I/O。
推 ericinttu:I/O吃多重,也要看要編的程式的特性. 就這個而言,換成SSD
→ ericinttu:應該沒有差 (應該只有 CPU-快取-ram 這樣的存取動作)
→ james732:原來是CPU比較重，我笨了...
→ angleevil:樓上謙虛了
→ james732:不，上過成功嶺真的會變笨...XD
→ ericinttu:不知道你的.obj編出來多大? 我用程式碼產生器產生一個
→ ericinttu:類似的程式, .obj: 1997kb
→ tropical72:obj : 2,459 KB
→ chengcti:static 太多..