编译的优化方法

㈠ 编译的代码优化

代码优化是指对程序进行多种等价变换，使得从变换后的程序出发，能生成更有效的目标代码。所谓等价，是指不改变程序的运行结果。所谓有效，主要指目标代码运行时间较短，以及占用的存储空间较小。这种变换称为优化。
有两类优化：一类是对语法分析后的中间代码进行优化，它不依赖于具体的计算机；另一类是在生成目标代码时进行的，它在很大程度上依赖于具体的计算机。对于前一类优化，根据它所涉及的程序范围可分为局部优化、循环优化和全局优化三个不同的级别。

㈡ 如何优化 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%。如果开发人员立刻为每一个列表中的文件建立其各自的规则, 则会处于更灵活有效的位置。这样一来改变优化只会引起一小部分文件被重新编译。进而,由于时间不会浪费在优化不费时的函数上, 重编译全部文件将会大大地加快。