含有代码优化的编译程序执行效率

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从技术上说是个不错的选择，只是用户群还太小。