含有代碼優化的編譯程序執行效率

A. 編譯的代碼優化

代碼優化是指對程序進行多種等價變換，使得從變換後的程序出發，能生成更有效的目標代碼。所謂等價，是指不改變程序的運行結果。所謂有效，主要指目標代碼運行時間較短，以及佔用的存儲空間較小。這種變換稱為優化。
有兩類優化：一類是對語法分析後的中間代碼進行優化，它不依賴於具體的計算機；另一類是在生成目標代碼時進行的，它在很大程度上依賴於具體的計算機。對於前一類優化，根據它所涉及的程序范圍可分為局部優化、循環優化和全局優化三個不同的級別。

B. 含優化部分的編譯程序執行效率高 對嗎

不能說一定高，優化一個最主要目的是解決程序佔用存儲空間大。

C. 程序優化技術都有哪些，如何提高程序的執行效率

個人理解：
1）說的是程序是要供人去讀，去維護，因此不能為了效率犧牲這方面的性能，導致程序難以理解，維護。那樣，正確性，可靠性及健壯性就無從談起了。
2） 是說要首先著眼於全局的優化，譬如路徑是否合理，有沒有多餘的步驟，有沒有多餘的循環？
3） 找出瓶頸的意思是說，程序可能由若干步驟、若幹部分組成。有可能大多數步驟的效率都是100，個別步驟的是10，你應該先優化效率低的這些地方。
4） 數據結構與實際要描述的對象，你要進行合理的優化，去除不必要的冗餘，等等。而演算法的優化，你可以看一個在一列排好序的數列中查找一個給定數的演算法，一般講演算法的書上。採用不同的演算法效率是大不一樣的，這比僅僅優化代碼的效果要好得多。
5） 效率分為（存儲）空間效率和時間效率，這兩者一般比較難以統一，往往要在兩者之間權衡。不過隨著計算機技術的發展，現在一般計算機都可以提供足夠的空間，因此空間效率往往已經不成為問題了。你只要專注於提高時間效率就可以了！
6） 緊湊的代碼主要是去除了好多必要的格式字元達成的。實際執行的機器碼都是經過編譯產生的，而編譯過程中機器會自動過濾掉格式字元，因此是否去除格式字元對編譯產生的機器碼沒有什麼影響。

D. 在編譯原理中，代碼優化功能模塊可以產生效率較高的目標代碼，不能使編譯工作本身速度加快。

就是提高運行效率的 比如 值編號冗餘消除
t1 = a + b;
t2 = a + b;
值編號後（假設a + b編號為e1）發現賦值表達式的右操作數一樣 ，則
可以優化成 t1 = a + b; t2 = t1;
再如窺孔優化：如發現a = a+ 1;這樣的表達式 則可以優化成a++;後者自增運算的機器周期要低於前者加法運算的 就是這些了。。。

E. 含有代碼優化的編譯器的執行效率高這句話對不對

優化方式理論上跟編譯器和硬體都有關聯。代碼級別的優化，要看所使用的編譯器實現，Xcode用的是clang，VS用的是windows自己的編譯器。。。
匯編級別（指令級別）的優化，要根據硬體對應的指令集實現，指令集根據CPU類型的不同而不同。。。

F. 編譯原理課程的習題··

作為一個課程習題,應先自行動腦解決,如果不能答找書找老師,如果有問題,網上可探討.
把原文放網上在向網路要答案,交作業完工,這不是學習,是自殺性讀書法.你能學到的,唯一就是會打字了,也許打字也不是你打的,那就是會復制粘貼了.
當你畢業之後,還有地方復制嗎?自殺吧,出有出路,不學無術.

G. 編譯後的程序比邊解釋邊執行的程序的運行速度快嗎為什麼

程序的編譯是指將人可以理解的代碼(如C的源代碼)段編譯成機器指令碼（二級制指令），也就是處理堆棧、處理器、匯流排的指令，交由計算機自動執行。解釋型語言是在需要執行時臨時編譯運行，執行時多了編譯的過程，自然就要慢的多了。
比較特殊的是java,javac命令編譯的結果雖然也是二進制文件，但實際也不是機器指令，而是優化後的代碼，最後的執行是通過java虛擬機再次編譯後執行。所以效率介於編譯型和解釋型之間。
目前java的執行速度已經有了大幅度的提升，但要想趕上或超越C 或者匯編，理論上是不現實的。

H. 如何優化JAVA代碼及提高執行效率

1、 盡量指定類的final修飾符帶有final修飾符的類是不可派生的。在Java核心API中，有許多應用final的例子，例如java.lang.String。為String類指定final防止了人們覆蓋length()方法。另外，如果指定一個類為final，則該類所有的方法都是final。Java編譯器會尋找機會內聯（inline）所有的final方法（這和具體的編譯器實現有關）。此舉能夠使性能平均提高50% 。
2、 盡量重用對象。特別是String 對象的使用中，出現字元串連接情況時應用StringBuffer 代替。由於系統不僅要花時間生成對象，以後可能還需花時間對這些對象進行垃圾回收和處理。因此，生成過多的對象將會給程序的性能帶來很大的影響。
3、 盡量使用局部變數，調用方法時傳遞的參數以及在調用中創建的臨時變數都保存在棧（Stack）中，速度較快。其他變數，如靜態變數、實例變數等，都在堆（Heap）中創建，速度較慢。另外，依賴於具體的編譯器/JVM，局部變數還可能得到進一步優化。請參見《盡可能使用堆棧變數》。

I. c語言的編譯效率是最快的嗎

計算機不能直接理解高級語言，只能直接理解機器語言，所以必須要把高級語言翻譯成機器語言，計算機才能執行高級語言編寫的程序。翻譯的方式有兩種，一個是編譯，一個是解釋。兩種方式只是翻譯的時間不同。編譯型語言寫的程序執行之前，需要一個專門的編譯過程，把程序編譯成為機器語言的文件，比如exe文件，以後要運行的話就不用重新翻譯了，直接使用編譯的結果就行了（exe文件），因為翻譯只做了一次，運行時不需要翻譯，所以編譯型語言的程序執行效率高，但也不能一概而論，部分解釋型語言的解釋器通過在運行時動態優化代碼，甚至能夠使解釋型語言的性能超過編譯型語言。解釋則不同，解釋性語言的程序不需要編譯，省了道工序，解釋性語言在運行程序的時候才翻譯，比如解釋性basic語言，專門有一個解釋器能夠直接執行basic程序，每個語句都是執行的時候才翻譯。這樣解釋性語言每執行一次就要翻譯一次，效率比較低。解釋是一句一句的翻譯。編譯型與解釋型，兩者各有利弊。前者由於程序執行速度快，同等條件下對系統要求較低，因此像開發操作系統、大型應用程序、資料庫系統等時都採用它，像C/C++、Pascal/Object Pascal（Delphi）等都是編譯語言，而一些網頁腳本、伺服器腳本及輔助開發介面這樣的對速度要求不高、對不同系統平台間的兼容性有一定要求的程序則通常使用解釋性語言，如Java、JavaScript、VBScript、Perl、Python、Ruby、MATLAB 等等。但隨著硬體的升級和設計思想的變革，編譯型和解釋型語言越來越籠統，主要體現在一些新興的高級語言上，而解釋型語言的自身特點也使得編譯器廠商願意花費更多成本來優化解釋器，解釋型語言性能超過編譯型語言也是必然的。

J. 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從技術上說是個不錯的選擇，只是用戶群還太小。