編譯器速度

A. 為什麼我用dev c++編譯運行時速度突然變得很慢

我也遇到過這種情況，不要擔心，之後每一次編譯不會都這么慢。
可能性有很多。很可能是使用大量STL導致的（STL裡面的模板會拖慢編譯速度）。
當然也有可能是編譯器當時抽風（很多時候第二次編譯就快很多）

B. 如何提高pb9編譯程序速度

執行與編譯。。也有掛鉤！。。執行、編譯速度又跟硬體有關！用 WEB來說 第一次編譯比較慢！後面這次訪問就快多了！這跟緩存有關。。還有就是代碼的問題。。 多次的循環判斷也會造成系統執行變慢！。。在提升速度方面 主要就是倆種方法 1.完善的代碼 2.提高硬體了！可能我說的比較片面！別的兄弟可以繼續補充！

C. delphi編譯器效率高到底是指什麼

所謂delphi編譯器效率高，一般指的是以下三方面：

1、編譯連接時間短，這一點是其他任何編譯器都無法相比的（一般來說，VC, VB編譯過程所用的時間是Delphi的幾倍），原因很簡單：Pascal語法限制嚴格，用戶必須規范地編碼，省去了編譯器的很多麻煩。

2、編譯出的程序執行速度快，產生的代碼長度短。這一點比VB強，但和VC基本一樣，誰也沒有優勢。不過很多人有誤解，以為Delphi類庫龐大復雜，加一個控制項就要把整個一個源文件全部加進來，代碼長度太大，效率太差。其實真實情況是，擁有眾多VCL控制項類庫，是Delphi的一個獨特之處，VC的MFC庫無法與之相比——MFC有的底層簡單封裝的類，VCL庫都有，但VCL有的上層組件，MFC卻根本沒有。使用VCL上層應用控制項後，代碼長度的確比VC大，不過VC卻沒有這方面的選擇，而VC所用的從底層一磚一瓦地編碼的方式，Delphi完全支持，而且絕對沒任何劣勢，代碼長度也不長（VC的語法復雜，按C程序員一般習慣做的話，代碼長的反而會是VC）。產生誤解的原因，是多數Delphi程序員是應用級的，而VC程序員是底層些的，應用程序員大多不太懂得底層代碼的編寫，只會搬控制項、響應事件，以為底層的東西Delphi做不來。

3、對應用級的程序開發周期短——這也就是Borland一貫吹捧的「快速開發工具」的含義。正因為VCL的存在（封裝了很多界面組件以及通訊、資料庫、internet應用等很多後台功能），對高層應用不再需要一磚一瓦地受累，使開發周期縮短了很多倍。

單純從技術角度說，編譯器效率應該指編譯出的代碼是否短小/運行速度是否快，以及是否能用較少的源代碼高效地實現復雜功能。前一方面Delphi並不比VC差，而比VB強，但並非一騎絕塵；後一方面則的確有一騎絕塵之象。

Delphi的致命缺點，其實不是技術——技術它是領先的，毫無疑問，問題是市場策略和公司實力（Borland只是家小公司），微軟「攜操作系統以令諸侯」，誤導了眾多軟體開發公司，讓它們以為微軟的才正宗和好用，造成了事實上的VB，VC用戶群遠比Borland的龐大，源代碼數量也一樣是C/C++遠遠占優，而Borland的C++ Builder卻開發得太晚難以形成市場優勢。

概括來說，如果你要開發上層應用為主的程序，特別是資料庫方面的程序，那麼Delphi能讓你省不少時間；而若開發底層些的軟體，為能有更多相關代碼可以參考利用，為能容易地招聘到更合適的程序員，以及為了代碼維護方便，都適合用C/C++去做，當然，C++ Builder從技術上說是個不錯的選擇，只是用戶群還太小。

D. c++builder編譯速度太慢，能不能通過設置來加快

C＋＋builder是最快的C＋＋編譯器之一，從編譯速度來說也可以說是最快的win32C＋＋編譯器了。除了速度之外，C++builder的性能也在其它C＋＋編譯器的之上，但許多delphi程序員仍受不了c++builder工程的編譯速度。的確，delphi的速度要比任和c++的編譯器都要快好多。Delphi在編譯一個小工程的時候可能不到一秒，大的工程一般也在5秒鍾這內編譯完成了。

為什麼delphi會比c++builder快這么多？是否有方法來c++builder的編譯速度？本文就講解了為什麼C＋＋的編譯器速度會慢，並且介紹了一個簡單的方法來減少c++builder的編譯時間。

為什麼c++編譯器的速度會慢？
c++builder 使用者怎麼通過預編譯頭文件來減少編譯時間？
講解基於VCL可視化工程的預編譯頭文件方法
優化c++builder對預編譯頭文件的使用
結論
注意事項

為什麼c++編譯器速度慢？

在C＋＋中，你只能使用預定義或是預先聲明了的函數，這意味什麼？來看一個簡單的例子，函數A()調用函數B（），函數A（）只能在函數B（）的原型或是函數體在A（）之前才能調用它

E. 為什麼Visual Studio 2010的編譯速度比Visual Studio 6.0慢很多，有什麼方法可以加快速度嗎

編譯器不同，使用的編譯方法不同，主要差異在代碼優化，智能糾錯等方面。6.0是上世紀的產物，連C++標准都實現的非常不完善，更何況代碼優化之類的特別費時的工作。隨著CPU和操作系統技術的發展，二進制代碼生成更加困難，優化更加復雜，當然最終代碼的執行效率會更高。
另一方面也是由於nt內核的代碼復雜度變的更高，vs2010的頭文件和6.0的版本是不同的，很多新的的系統特性都被加入到windows頭文件中。
加快速度的方法有禁用優化選項，禁用clr檢查等。最基本的還是良好的程序結構，能減少編譯器的工作量。vs在生成代碼的時候即使是release模式仍然會創建大量的調試信息在工程中，以幫助問題發現和恢復，在vc6時代是沒有這東西的。

F. 程序的編譯速度與程序的執行速度

執行與編譯。。也有掛鉤！。。執行、編譯速度又跟硬體有關！用 WEB來說 第一次編譯比較慢！後面這次訪問就快多了！這跟緩存有關。。還有就是代碼的問題。。 多次的循環判斷也會造成系統執行變慢！。。在提升速度方面 主要就是倆種方法 1.完善的代碼 2.提高硬體了！可能我說的比較片面！別的兄弟可以繼續補充！

G. 編譯器編譯的時間， 要比解釋語言運行的速度慢嗎為什麼

只能說說通常的情況，因為情況比較復雜
一般來說，編譯的語言比解釋性語言運行的速度塊
不過編譯時間的話就很難說了，和編譯器本身有關系
解釋語言可以不用專成 二進制代碼直接運行

H. 為什麼pascal的編譯速度比c快那麼多

編譯器好比一個應用程序，諸多的編譯器直接自然會有速度上的差異，根據編譯器功能的大小而定，一般，越大的編譯器，功能越多，編譯器源代碼來越慢，功能簡單的編譯器，編譯器源代碼來，速度就快得多。

I. 影響vs編譯速度的因素有哪些

影響因素比較多：
1 文件的大小，文件大小指的是全部include展開後的大小。
2 文件數量，編譯是一個一個文件進行的，所以你的工程的文件數量也有關系。
3 還有聲明的復雜程度，復雜聲明需要額外地計算。
4 最影響編譯速度的估計是C++的模板，模板在編譯的時候要進行推導，得到相應的結果，這個非常費時間。如果你是模板里還套了模板，那就比較慢了。
5 鏈接庫的數量，鏈接很多庫也會使得編譯速度變慢。
6 inline函數展開，會使得代碼膨脹，也會影響編譯速度
7 debug模式編譯要留符號表做調試，也會影響速度
8 release模式如果開了優化，編譯優化會改變代碼的某些結構，這也是拖慢編譯器的一個重要因素。

J. 華為方舟編譯器優化後的支付寶幾乎秒開，它為什麼這么厲害

提到華為方舟編譯器，我也是不明覺厲。其實我並不懂這個編譯器的強大，只是看到官方的報答說多麼多麼厲害，我才知道這個方舟原來是這么厲害的一個東西。據說以後使用這個編譯器做出來的APP將會更加的流暢，希望這次的改革能真正才超越蘋果IOS系統吧。

至於蘋果手機還有一個優勢，就是過度很流暢，可能安卓和蘋果打開一個軟體同樣用2秒吧，你能感覺到蘋果看著更加流暢相比安卓而言，所以說現在安卓最好的狀態也就是和蘋果打一個平手，說超越那都是虛妄。不知道這次方舟編譯器的誕生能不能改變這個局面，讓安卓的系統真正的超越蘋果，也使得很多因為系統不得不忍受蘋果手機煎熬的人能解脫出來。其實這樣的人很多，因為感覺安卓不夠流暢，所以無奈才選擇蘋果手機的人不在少數。