现代编译器以性能为代价，编译速度最多能快多少倍，此时性能损耗有多大？

就为了编译快？牺牲性能？

最快的应该是直接把源代码拷到 release 目录，直接把编译器压一起……
执行时候再编译呗

@realpg 我其实是想了解，解释型语言为什么在某些场合比编译型语言有优势……

不就是 python 和 C 的区别么

@schezukNewTos #2
解释型语言开发效率更高

@liuzhedash 但是执行效率更慢（始终比不上 C ，当然也要看使用场景，逃~

@schezukNewTos #2

解释性语言执行时才编译，可以实现一些编译性语言无法实现的"奇巧淫技"
例如： php 中的 extract()，可以实现把数组中将变量导入到当前的符号表（简单来说，就是把数组中的 key 作为变量名， value 作为值来“生成”一堆变量）；

解释性语言一般是执行一行编译一行，执行过程中用不到的可以先不编译，开发的时候可以提升效率；

跨平台时不用针对目标平台进行任何额外的工作

@schezukNewTos 解释型的用开发速度换运行速度，大概就是这个差别。
Python 这种上了 Cython ，配合合适的策略，速度不见得比纯 C 慢很多。
https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en

不编译，直接放一个无限循环的程序上去，算吗？

所谓「解释型」是算是基于「虚拟机」的语言的一种简易实现。但除了 CPython 这个异端之外，其他基于虚拟机的语言都多多少少转向了 JIT ，在一些特定场景下已经可以和本地代码（你们说的「编译型」语言大概就是这个意思吧，毕竟 JIT 也有编译环节）一较高下了，之所以和本地代码仍有差距的原因其实更多是因为这些语言往往是「动态类型」而且有 GC 。

楼上各位多多少少混淆了这些概念，可以看下我近期的一篇文章 https://jysperm.me/2016/12/categories-of-languages

解释器在运行时会优化，极端情况下可以直接返回之前计算好的结果，而不必执行整段代码，这是编译型需要做不到的。

了解过 gcc llvm 的编译优化过程么？

v2 的人对 compiler 的了解仅限于此？

所以也不过都是一帮二字套餐的

@soulshell 愿闻其详。

性能损耗和语言特性有关，比如 c++可以给你优化掉内存访问、分支、跳转、虚函数、异常、值返回等等所有特性，但不优化的话估计和比 Java 不带 gc 的要差在内存访问、分支、跳转上。。。。还有前面的真的不是编译器不能优化的。

说不带 gc 是指 gc 会有很慢的时候啊，一般带上 gc 也挺快的。。。

这种极端的话就变成解释性语言了

楼主指的是啥编译器

我长期折腾 C++，感觉其他 compiled language 的编译器都快得要命，甚至完全没必要优化编译速度

比如第一次编译 OpenRA 的时候按惯例倒了杯水回来发现已经编译完了，一脸懵逼

@secondwtq OpenRA (C#/.NET) 这种东西基本翻译成 MSIL 之后优化就交给运行时了，和彻底的“编译时”作比较有点不妥吧……

google 的 go 编译器编译速度很快，但编译出来的东西执行也不见得慢。所以这种比较只能用单个编译器来讨论。
go 的 lexer 、 parser 都是并发的，后端的代码生成、链接等也将会并发执行，和 make -jX 这种做法不一样，单个 object 也是并发的，充分利用各个 cpu 核心，编译速度可以更快。