編譯的優化方法

㈠ 編譯的代碼優化

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

㈡ 如何優化 android Studio 啟動，編譯和運行速度

優化 Android Studio 啟動、編譯和運行速度？
【阿里雲】攜手碼雲為社區用戶送福利，全網專享，詳情請點擊>>> »
作為一名 Android 程序員，選擇一個好的 IDE 工具可以使開發變得非常高效，很多程序員喜歡使用 Google 的 Android Studio來進行開發，但使用起來有時會出現卡頓等問題。本文介紹了幾種優化 Android Studio 啟動、編譯、運行速度的方法。
首先解決一個 Android Studio 啟動報錯的問題
1、進入剛安裝的 Android Studio 目錄下的bin目錄。找到 idea.properties 文件，用文本編輯器打開。
2、在 idea.properties 文件末尾添加一行：disable.android.first.run=true，然後保存文件。
3、關閉 Android Studio 後重新啟動，便可進入界面。
優化 Android Studio 啟動速度
1、開啟 gradle 單獨的守護進程
當 Android Studio 遇到錯誤的時候，往往會導致 Android Studio 掛掉，為了防止推出程序，則另外開啟一個線程來守護 Android Studio 的進程，具體操作。 在 C:\Users\.gradle 這個目錄下，創建 gradle.properties 配置文件，復制以下配置進行優化。
# Project-wide Gradle settings.
org.gradle.daemon=true
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m
-XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
org.gradle.parallel=true
org.gradle.configureondemand=true

這些配置文件主要就是增大 gradle 運行的 java 虛擬機的大小，讓 gradle 在編譯的時候使用獨立進程，讓 gradle 可以很好的運行。
2、擴大內存
64位：\studio64.exe.vmoptions or studio.exe.vmoptions
32位：\studio.exe.vmoptions or studio.exe.vmoptions
編輯這個文件，在最開始的兩行設置內存大小，類似於eclipse.ini中的配置。配置如下：
-Xms256m
-Xmx1024m

㈢ 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 PU 執行周期。
盡管存在上述情況, 大多數Makefile文件只有一套編譯器選項來編譯項目中所有的文件。因此, 標準的優化方法只是簡單地提升優化選項的強度, 一般從O 2 到O 3。這樣一來, 就需要投人大量 精力來調試, 以確定哪些文件不能被優化, 並為這些文件建立特殊的make規則。
一個更簡單但更有效的方法是通過一個性能分析器, 來運行最初的代碼, 為那些佔用了85 一95 % CPU 的源文件生成一個列表。通常情況下, 這些文件大約只佔所有文件的1%。如果開發人員立刻為每一個列表中的文件建立其各自的規則, 則會處於更靈活有效的位置。這樣一來改變優化只會引起一小部分文件被重新編譯。進而,由於時間不會浪費在優化不費時的函數上, 重編譯全部文件將會大大地加快。