編譯器代碼優化

Ⅰ 編譯器的優化到底能夠優化到什麼程度

在不改變程序行為的前提下可以任意改寫代碼

Ⅱ 如何優化你的C代碼

一、程序結構的優化
1、程序的書寫結構
雖然書寫格式並不會影響生成的代碼質量，但是在實際編寫程序時還是應該尊循一定的書寫規則，一個書寫清晰、明了的程序，有利於以後的維護。在書寫程序時，特別是對於While、for、do…while、if…elst、switch…case等語句或這些語句嵌套組合時，應採用「縮格」的書寫形式，

2、標識符
程序中使用的用戶標識符除要遵循標識符的命名規則以外，一般不要用代數符號(如a、b、x1、y1)作為變數名，應選取具有相關含義的英文單詞(或縮寫)或漢語拼音作為標識符，以增加程序的可讀性，如：count、number1、red、work等。

3、程序結構
C語言是一種高級程序設計語言，提供了十分完備的規范化流程式控制制結構。因此在採用C語言設計單片機應用系統程序時，首先要注意盡可能採用結構化的程序設計方法，這樣可使整個應用系統程序結構清晰，便於調試和維護。於一個較大的應用程序，通常將整個程序按功能分成若干個模塊，不同模塊完成不同的功能。各個模塊可以分別編寫，甚至還可以由不同的程序員編寫，一般單個模塊完成的功能較為簡單，設計和調試也相對容易一些。在C語言中，一個函數就可以認為是一個模塊。所謂程序模塊化，不僅是要將整個程序劃分成若干個功能模塊，更重要的是，還應該注意保持各個模塊之間變數的相對獨立性，即保持模塊的獨立性，盡量少使用全局變數等。對於一些常用的功能模塊，還可以封裝為一個應用程序庫，以便需要時可以直接調用。但是在使用模塊化時，如果將模塊分成太細太小，又會導致程序的執行效率變低(進入和退出一個函數時保護和恢復寄存器佔用了一些時間)。

4、定義常數
在程序化設計過程中，對於經常使用的一些常數，如果將它直接寫到程序中去，一旦常數的數值發生變化，就必須逐個找出程序中所有的常數，並逐一進行修改，這樣必然會降低程序的可維護性。因此，應盡量當採用預處理命令方式來定義常數，而且還可以避免輸入錯誤。

5、減少判斷語句
能夠使用條件編譯(ifdef)的地方就使用條件編譯而不使用if語句，有利於減少編譯生成的代碼的長度，能夠不用判斷語句則少用判斷用語句。

6、表達式
對於一個表達式中各種運算執行的優先順序不太明確或容易混淆的地方，應當採用圓括弧明確指定它們的優先順序。一個表達式通常不能寫得太復雜，如果表達式太復雜，時間久了以後，自己也不容易看得懂，不利於以後的維護。

7、函數
對於程序中的函數，在使用之前，應對函數的類型進行說明，對函數類型的說明必須保證它與原來定義的函數類型一致，對於沒有參數和沒有返回值類型的函數應加上「void」說明。如果果需要縮短代碼的長度，可以將程序中一些公共的程序段定義為函數，在Keil中的高級別優化就是這樣的。如果需要縮短程序的執行時間，在程序調試結束後，將部分函數用宏定義來代替。注意，應該在程序調試結束後再定義宏，因為大多數編譯系統在宏展開之後才會報錯，這樣會增加排錯的難度。

8、盡量少用全局變數，多用局部變數。
因為全局變數是放在數據存儲器中，定義一個全局變數，MCU就少一個可以利用的數據存儲器空間，如果定義了太多的全局變數，會導致編譯器無足夠的內存可以分配。而局部變數大多定位於MCU內部的寄存器中，在絕大多數MCU中，使用寄存器操作速度比數據存儲器快，指令也更多更靈活，有利於生成質量更高的代碼，而且局部變數所的佔用的寄存器和數據存儲器在不同的模塊中可以重復利用。

9、設定合適的編譯程序選項
許多編譯程序有幾種不同的優化選項，在使用前應理解各優化選項的含義，然後選用最合適的一種優化方式。通常情況下一旦選用最高級優化，編譯程序會近乎病態地追求代碼優化，可能會影響程序的正確性，導致程序運行出錯。因此應熟悉所使用的編譯器，應知道哪些參數在優化時會受到影響，哪些參數不會受到影響。
在ICCAVR中，有「Default」和「Enable Code Compression」兩個優化選項。
在CodeVisionAVR中，「Tiny」和「small」兩種內存模式。
在IAR中，共有7種不同的內存模式選項。
在GCCAVR中優化選項更多，一不小心更容易選到不恰當的選項。

二、代碼的優化
1、選擇合適的演算法和數據結構
應該熟悉演算法語言，知道各種演算法的優缺點，具體資料請參見相應的參考資料，有很多計算機書籍上都有介紹。將比較慢的順序查找法用較快的二分查找或亂序查找法代替，插入排序或冒泡排序法用快速排序、合並排序或根排序代替，都可以大大提高程序執行的效率。.選擇一種合適的數據結構也很重要，比如你在一堆隨機存放的數中使用了大量的插入和刪除指令，那使用鏈表要快得多。
數組與指針語句具有十分密碼的關系，一般來說，指針比較靈活簡潔，而數組則比較直觀，容易理解。對於大部分的編譯器，使用指針比使用數組生成的代碼更短，執行效率更高。但是在Keil中則相反，使用數組比使用的指針生成的代碼更短。。

3、使用盡量小的數據類型
能夠使用字元型(char)定義的變數，就不要使用整型(int)變數來定義；能夠使用整型變數定義的變數就不要用長整型(long int)，能不使用浮點型(float)變數就不要使用浮點型變數。當然，在定義變數後不要超過變數的作用范圍，如果超過變數的范圍賦值，C編譯器並不報錯，但程序運行結果卻錯了，而且這樣的錯誤很難發現。
在ICCAVR中，可以在Options中設定使用printf參數，盡量使用基本型參數(%c、%d、%x、%X、%u和%s格式說明符)，少用長整型參數(%ld、%lu、%lx和%lX格式說明符)，至於浮點型的參數(%f)則盡量不要使用，其它C編譯器也一樣。在其它條件不變的情況下，使用%f參數，會使生成的代碼的數量增加很多，執行速度降低。

4、使用自加、自減指令
通常使用自加、自減指令和復合賦值表達式(如a-=1及a+=1等)都能夠生成高質量的程序代碼，編譯器通常都能夠生成inc和dec之類的指令，而使用a=a+1或a=a-1之類的指令，有很多C編譯器都會生成二到三個位元組的指令。在AVR單片適用的ICCAVR、GCCAVR、IAR等C編譯器以上幾種書寫方式生成的代碼是一樣的，也能夠生成高質量的inc和dec之類的的代碼。

5、減少運算的強度
可以使用運算量小但功能相同的表達式替換原來復雜的的表達式。如下：

(1)、求余運算。
a=a%8;
可以改為：
a=a&7;
說明：位操作只需一個指令周期即可完成，而大部分的C編譯器的「%」運算均是調用子程序來完成，代碼長、執行速度慢。通常，只要求是求2n方的余數，均可使用位操作的方法來代替。

(2)、平方運算
a=pow(a,2.0);
可以改為：
a=a*a;
說明：在有內置硬體乘法器的單片機中(如51系列)，乘法運算比求平方運算快得多，因為浮點數的求平方是通過調用子程序來實現的，在自帶硬體乘法器的AVR單片機中，如ATMega163中，乘法運算只需2個時鍾周期就可以完成。既使是在沒有內置硬體乘法器的AVR單片機中，乘法運算的子程序比平方運算的子程序代碼短，執行速度快。

如果是求3次方，如：
a=pow(a,3.0);
更改為：
a=a*a*a；
則效率的改善更明顯。

(3)、用移位實現乘除法運算
a=a*4;
b=b/4;
可以改為：
a=a<<2;
b=b>>2;
說明：通常如果需要乘以或除以2n，都可以用移位的方法代替。在ICCAVR中，如果乘以2n，都可以生成左移的代碼，而乘以其它的整數或除以任何數，均調用乘除法子程序。用移位的方法得到代碼比調用乘除法子程序生成的代碼效率高。實際上，只要是乘以或除以一個整數，均可以用移位的方法得到結果，如：
a=a*9
可以改為：
a=(a<<3)+a

6、循環
(1)、循環語
對於一些不需要循環變數參加運算的任務可以把它們放到循環外面，這里的任務包括表達式、函數的調用、指針運算、數組訪問等，應該將沒有必要執行多次的操作全部集合在一起，放到一個init的初始化程序中進行。

(2)、延時函數：
通常使用的延時函數均採用自加的形式：
void delay (void)
{
unsigned int i;
for (i=0;i<1000;i++)
;
}
將其改為自減延時函數：
void delay (void)
{
unsigned int i;
for (i=1000;i>0;i--)
;
}
兩個函數的延時效果相似，但幾乎所有的C編譯對後一種函數生成的代碼均比前一種代碼少1~3個位元組，因為幾乎所有的MCU均有為0轉移的指令，採用後一種方式能夠生成這類指令。
在使用while循環時也一樣，使用自減指令控制循環會比使用自加指令控制循環生成的代碼更少1~3個字母。
但是在循環中有通過循環變數「i」讀寫數組的指令時，使用預減循環時有可能使數組超界，要引起注意。

(3)while循環和do…while循環
用while循環時有以下兩種循環形式：
unsigned int i;
i=0;
while (i<1000)
{
i++;
//用戶程序
}
或：
unsigned int i;
i=1000;
do
i--;
//用戶程序
while (i>0);
在這兩種循環中，使用do…while循環編譯後生成的代碼的長度短於while循環。

7、查表
在程序中一般不進行非常復雜的運算，如浮點數的乘除及開方等，以及一些復雜的數學模型的插補運算，對這些即消耗時間又消費資源的運算，應盡量使用查表的方式，並且將數據表置於程序存儲區。如果直接生成所需的表比較困難，也盡量在啟動時先計算，然後在數據存儲器中生成所需的表，後以在程序運行直接查表就可以了，減少了程序執行過程中重復計算的工作量。

Ⅲ 應用編譯優化有什麼用

應用編譯優化的作用是：提高運行能力因為程序優化前，有3個變數需要3個寄存器，一次乘法運算。程序優化後，只有1個變數需要一個寄存器，沒有乘法運算。

並且這個優化看起來很微不足道，但實際上用途很廣。為了程序的可讀性和可維護性，大多數程序員應該還是會選用第一種方式。

寫3行程序而不是直接甩下一行int ticks = 491520讓後來讀程序的人摸不到頭腦。有了編譯器的優化，程序員既可以寫出易讀的程序又不必擔心性能受影響。

尤其是在嵌入式領域，很多低端晶元根本就沒有硬體乘法器，如果程序不做上述優化可能這3行代碼需要幾十個cycle，優化過後一個cycle就搞定。

應用編譯優化的級別：

第一級：代碼調整。

代碼調整是一種局部的思維方式；基本上不觸及演算法層級；它面向的是代碼，而不是問題； 所以：語句調整，用匯編重寫、指令調整、換一種語言實現、換一個編譯器、循環展開、參數傳遞優化等都屬於這一級。

第二級：新的視角。

新的視角強調的重點是針對問題的演算法；即選擇和構造適合於問題的演算法。

第三級：表驅動狀態機。

將問題抽象為另一種等價的數學模型或假想機器模型，比如構造出某種表驅動狀態機；這一級其實是第二級的延伸，只是產生的效果更加明顯，但它有其本身的特點。

Ⅳ java如何優化編譯呢

#java編譯器對`String常量表達式`的優化:
- 1.String+String 可以被編譯器識別為常量表達
String a="ab" ;
String b="a"+"b";//編譯後:b="ab"
System.out.println(a==b);//true
分析:
編譯器將"a"+"b"當做常量表達式,在編譯時期進行優化,直接取"ab". 在運行時期
並沒有創建新的對象,而是從jvm字元串常量池中獲取之前已經存在的"ab"對象.

- 2.String+基本類型 可以被編譯器識別為常量表達式

String a="a1";
String b="a"+1; //"a1"
String c="a"+true;//"atrue"
String d="a"+3.14;//"a3.14"

#java編譯器對`常量`優化:
* 它是編譯時的一項優化技術,將代碼的常量計算在編譯期完成,節約了運行時的計算量.

1.常量替換
//編譯前:
final int x=10;
int y=x;

//編譯後
int x=10;
int y=10;//編譯時,常量替換了

2.數學恆等式的模式匹配替換

//編譯前:
int x=10+10;

//編譯後
int x=20;//編譯時,模式匹配替換了

3.常量折疊

//編譯前:
boolean flag=true||(a || b && c);

//編譯後
boolean flag=true;//編譯時,常量折疊了

Ⅳ 也談「C++編譯器到底能幫我們把代碼優化到什麼程度

也談「C++編譯器到底能幫我們把代碼優化到什麼程度
這個取決於編譯器廠家了，不同的編譯器優化有異同，編譯器優化對性能影響很大，有時會有驚喜

Ⅵ 編譯器 優化

編譯是從源代碼（通常為高階語言）到能直接被計算機或虛擬機執行的目標代碼（通常為低階語言或機器語言）的翻譯過程。然而，也存在從低階語言到高階語言的編譯器，這類編譯器中用來從由高階語言生成的低階語言代碼重新生成高階語言代碼的又被叫做反編譯器。也有從一種高階語言生成另一種高階語言的編譯器，或者生成一種需要進一步處理的的中間代碼的編譯器（又叫級聯）。
典型的編譯器輸出是由包含入口點的名字和地址, 以及外部調用（到不在這個目標文件中的函數調用）的機器代碼所組成的目標文件。一組目標文件，不必是同一編譯器產生，但使用的編譯器必需採用同樣的輸出格式，可以鏈接在一起並生成可以由用戶直接執行的可執行程序。
從他的原理我們就好優化了，但是方法很多的

Ⅶ 什麼叫代碼優化為什麼要優化

C語言屬於編譯語言，也就是你編寫的程序，要經過編譯形成目標代碼，具體的處理器才能執行這個程序。
C語言的編譯器有多種演算法，如代碼長度最小、代碼執行時間最短等等。你在開發環境中不對代碼優化進行設置，那就是默認等級，或者叫無優化。
優化的目的是給用戶一個選擇，比如你的程序存儲器只有8K，可是編譯出來的代碼是9K，那你是沒法燒錄運行的，裝不下。這時你按代碼長度最小優化一下，也許就可以了。
不優化沒什麼問題，大不了程序大一點，優化級別越高，出問題的可能性越大。因為編譯軟體只有一個，程序員千千萬，優化難免有BUG。

原則：能不優化就不優化，需要優化先自己想辦法，實在不行才藉助編譯軟體優化，但要詳細測試。

Ⅷ java編譯器的代碼優化問題

理論上的就不說了，你自己搜也能搜到很多。
舉個例子，你從一個方法a調用了另一個方法b。
我們知道，在a和b之中是可以創建相同名稱的變數的，比如都有int i = 0;這句話。這種現象的根本原因在於，方法的調用會產生中斷，中斷產生後，cpu會做現場保護，包括把變數等進行壓棧操作，即把方法a的相關資源進行了壓棧，而方法b的相關資源放在棧頂，只有棧頂資源可以與cpu交互（就把方法a中的變數i保護起來），當方法b結束後出棧，a就又回到了棧頂，並獲取了方法b運行的結果，然後繼續運行。

哎，有些啰嗦了。方法的調用、中斷、壓棧出棧等等這些操作你說一點不消耗資源吧，那是不可能的，多少都會消耗一些，雖然很非常十分微不足道。那麼編譯器的優化過程，我知道的其作用之一，就是會把這些做一個優化。原本方法a一共10句話，你偏要只寫1句，然後第2句寫成方法b，第3句寫成方法c。。。。。，然後依次嵌套調用。這樣的源代碼，編譯器優化後，就跟你直接寫10句是一個結果，即做了一定程度上的優化。

Ⅸ 編譯器的編譯器優化

應用程序之所以復雜, 是由於它們具有處理多種問題以及相關數據集的能力。實際上, 一個復雜的應用程序就象許多不同功能的應用程序「 粘貼」 在一起。源文件中大部分復雜性來自於處理初始化和問題設置代碼。這些文件雖然通常占源文件的很大一部分, 具有很大難度, 但基本上不花費C PU 執行周期。
盡管存在上述情況, 大多數Makefile文件只有一套編譯器選項來編譯項目中所有的文件。因此, 標準的優化方法只是簡單地提升優化選項的強度, 一般從O 2 到O 3。這樣一來, 就需要投人大量 精力來調試, 以確定哪些文件不能被優化, 並為這些文件建立特殊的make規則。
一個更簡單但更有效的方法是通過一個性能分析器, 來運行最初的代碼, 為那些佔用了85 一95 % CPU 的源文件生成一個列表。通常情況下, 這些文件大約只佔所有文件的1%。如果開發人員立刻為每一個列表中的文件建立其各自的規則, 則會處於更靈活有效的位置。這樣一來改變優化只會引起一小部分文件被重新編譯。進而,由於時間不會浪費在優化不費時的函數上, 重編譯全部文件將會大大地加快。