『壹』 程序編譯總要很長時間，怎麼提高效率
採用模塊化開發, 不開發的就不引用, 這樣可大大加快編譯速度.
我們項目目前約70W行代碼, 純AS, 但開發各司其職, 最後統一builder
『貳』 為什麼Visual Studio 2010的編譯速度比Visual Studio 6.0慢很多，有什麼方法可以加快速度嗎
編譯器不同，使用的編譯方法不同，主要差異在代碼優化，智能糾錯等方面。6.0是上世紀的產物，連C++標准都實現的非常不完善，更何況代碼優化之類的特別費時的工作。隨著CPU和操作系統技術的發展，二進制代碼生成更加困難，優化更加復雜，當然最終代碼的執行效率會更高。
另一方面也是由於nt內核的代碼復雜度變的更高，vs2010的頭文件和6.0的版本是不同的，很多新的的系統特性都被加入到windows頭文件中。
加快速度的方法有禁用優化選項，禁用clr檢查等。最基本的還是良好的程序結構，能減少編譯器的工作量。vs在生成代碼的時候即使是release模式仍然會創建大量的調試信息在工程中，以幫助問題發現和恢復，在vc6時代是沒有這東西的。
『叄』 c語言的編譯效率是最快的嗎
計算機不能直接理解高級語言，只能直接理解機器語言，所以必須要把高級語言翻譯成機器語言，計算機才能執行高級語言編寫的程序。翻譯的方式有兩種，一個是編譯，一個是解釋。兩種方式只是翻譯的時間不同。編譯型語言寫的程序執行之前，需要一個專門的編譯過程，把程序編譯成為機器語言的文件，比如exe文件，以後要運行的話就不用重新翻譯了，直接使用編譯的結果就行了（exe文件），因為翻譯只做了一次，運行時不需要翻譯，所以編譯型語言的程序執行效率高，但也不能一概而論，部分解釋型語言的解釋器通過在運行時動態優化代碼，甚至能夠使解釋型語言的性能超過編譯型語言。解釋則不同，解釋性語言的程序不需要編譯，省了道工序，解釋性語言在運行程序的時候才翻譯，比如解釋性basic語言，專門有一個解釋器能夠直接執行basic程序，每個語句都是執行的時候才翻譯。這樣解釋性語言每執行一次就要翻譯一次，效率比較低。解釋是一句一句的翻譯。編譯型與解釋型，兩者各有利弊。前者由於程序執行速度快，同等條件下對系統要求較低，因此像開發操作系統、大型應用程序、資料庫系統等時都採用它，像C/C++、Pascal/Object Pascal（Delphi）等都是編譯語言，而一些網頁腳本、伺服器腳本及輔助開發介面這樣的對速度要求不高、對不同系統平台間的兼容性有一定要求的程序則通常使用解釋性語言，如Java、JavaScript、VBScript、Perl、Python、Ruby、MATLAB 等等。但隨著硬體的升級和設計思想的變革，編譯型和解釋型語言越來越籠統，主要體現在一些新興的高級語言上，而解釋型語言的自身特點也使得編譯器廠商願意花費更多成本來優化解釋器，解釋型語言性能超過編譯型語言也是必然的。
『肆』 編程語言越高級，程序的編譯效率越低，是真的嗎
額，編程語言高級人使用的更方便，但是在編譯的時候就更復雜，所以效率會下降。但是高質量高效率的軟體是由高級語言編寫的，因為程序編譯成功後不需要再編譯了。高級語言寫的軟體一樣可以擁有非常高的效率。如果用匯編寫一個大型程序，不僅編程復雜，而且很多功能無法實現。
『伍』 1. 單選題下列選項中,哪一個不能通過編譯( )。Abyte a
第2行確實會出錯，原因有兩個：1:protectied 不是關鍵字，正確的應該是protected2:toString( )i ,方法的括弧後面不能出現無意義的字元串
『陸』 影響vs編譯速度的因素有哪些
影響因素比較多：
1 文件的大小，文件大小指的是全部include展開後的大小。
2 文件數量，編譯是一個一個文件進行的，所以你的工程的文件數量也有關系。
3 還有聲明的復雜程度，復雜聲明需要額外地計算。
4 最影響編譯速度的估計是C++的模板，模板在編譯的時候要進行推導，得到相應的結果，這個非常費時間。如果你是模板里還套了模板，那就比較慢了。
5 鏈接庫的數量，鏈接很多庫也會使得編譯速度變慢。
6 inline函數展開，會使得代碼膨脹，也會影響編譯速度
7 debug模式編譯要留符號表做調試，也會影響速度
8 release模式如果開了優化，編譯優化會改變代碼的某些結構，這也是拖慢編譯器的一個重要因素。
『柒』 什麼是提高程序效率的最好方法
選擇好的演算法， 小心地實現， 同時確定程序不做額外的事。例如， 即使世界上最優化的字元復制循環也比不上不用復制。
當擔心效率時， 要保持幾樣事情在視野中， 這很重要。首先， 雖然效率是個非常流行的話題， 它並不總是象人們想的那樣重要。大多數程序的大多數代碼並不是時間緊要的。當代碼不是時間緊要時， 通常把代碼寫得清楚和可移植比達到最大效率更重要。記住， 電腦運行得非常非常快， 那些看起來 「低效率」 的代碼， 也許可以編譯得比較有效率， 而運行起來也沒有明顯的延時。
試圖預知程序的 「熱點」 是個非常困難的事。當要關心效率時， 使用 profiling軟體來確定程序中需要得到關注的地方。通常， 實際計算時間都被外圍任務佔用了 (例如 I/O 或內存的分配)， 可以通過使用緩沖和超高速緩存來提高速度。
即使對於時間緊要的代碼， 最無效的優化技巧是忙亂於代碼細節。許多常被建議的 「有效的代碼技巧」， 即使是很簡單的編譯器也會自動完成 (例如， 用移位運算符代替二的冪次方乘)。非常多的手動優化有可能是代碼變得笨重而使效率反而低下了， 同時幾乎不可移植。例如， 也許可以在某台機器上提了速， 但在另一台機器上去變慢了。任何情況下， 修整代碼通常最多得到線性信能提高; 更好的演算法可以得到更好的回報。
『捌』 編譯原理判斷題
1. B 正確
2. A 錯誤，不一定存在
3. B 正確
4. B 正確
5. A 錯誤，是後綴式
6. A 錯誤，只是算符文法，不一定是算符優先文法
7. B 正確
8. B 正確
9. A 錯誤，語義動作是附加在產生式上的，不是附加在非終結符上
10. A 錯誤，有些文法不能改寫為LL(1)文法
11. B 正確
12. B 正確
13. B 正確
14. B 正確
15. A 錯誤，SLR(1),LR(1)等都是沖突解決的辦法
16. B 正確
17. B 正確
18. A 錯誤，不是編譯程序工作效率高，而是生成的目標程序運行效率高
19. B 正確
『玖』 什麼工具可以提升gcc編譯效率
這個一般的工具應該還是做不到的，但是工具欄上應該還是有制動編譯的功效，你看一看。
『拾』 在編譯原理中，代碼優化功能模塊可以產生效率較高的目標代碼，不能使編譯工作本身速度加快。
就是提高運行效率的 比如 值編號冗餘消除
t1 = a + b;
t2 = a + b;
值編號後（假設a + b編號為e1）發現賦值表達式的右操作數一樣 ，則
可以優化成 t1 = a + b; t2 = t1;
再如窺孔優化：如發現a = a+ 1;這樣的表達式 則可以優化成a++;後者自增運算的機器周期要低於前者加法運算的 就是這些了。。。