我们可以将其分为两大类静态绑定和动态绑定。它取决于何时与相应值绑定。如果引用是在编译时解析的，那么它是静态绑定;如果引用是在运行时解析的，那么它是动态绑定。静态绑定和动态绑定又称早期绑定和后期绑定。有时也称为静态多态和动态多态。

约瑟夫Kulandai‏。

基本上，如果你的编译器能在“编译时”找出你的意思或一个值是什么，它就能硬编码到运行时代码中。显然，如果你的运行时代码每次都要进行计算，那么它会运行得更慢，所以如果你能在编译时确定一些东西，那就更好了。

Eg.

常数合并:

如果我这样写:

int i = 2;
i += MY_CONSTANT;

编译器可以在编译时执行这个计算，因为它知道2是什么，MY_CONSTANT是什么。因此，每次执行时，它都不必执行计算。

我一直认为它与程序处理开销以及它如何影响性能有关，如前所述。一个简单的例子是，在代码中定义对象所需的绝对内存。

一个定义的布尔值占用x个内存，然后在编译后的程序中，不能更改。当程序运行时，它确切地知道为x分配多少内存。

另一方面，如果我只是定义了一个泛型对象类型(即一种未定义的占位符或可能是一个指向一些巨大blob的指针)，我的对象所需的实际内存是不知道的，直到程序运行，我分配了一些东西给它，因此它必须评估和内存分配等，然后将在运行时动态处理(更多的运行时开销)。

如何动态处理它取决于语言、编译器、操作系统、你的代码等等。

然而，在这一点上，它实际上取决于您使用运行时和编译时的上下文。

简单地说，b/w编译时间和运行时间的差异。

编译时:开发人员以.java格式编写程序，并将其转换为类文件字节码，在编译期间发生的任何错误都可以定义为编译时错误。

运行时:生成的.class文件被应用程序用于它的附加功能&逻辑是错误的，并抛出一个错误，这是一个运行时错误

编制时间:

在编译时执行的操作在最终程序运行时几乎不会产生任何开销，但在构建程序时可能会产生很大开销。

运行时:

或多或少完全相反。构建时成本小，运行程序时成本大。

从另一边;如果在编译时执行了某些操作，那么它只在您的机器上运行;如果在运行时执行了某些操作，那么它将在用户的机器上运行。

相关性

An example of where this is important would be a unit carrying type. A compile time version (like Boost.Units or my version in D) ends up being just as fast as solving the problem with native floating point code while a run-time version ends up having to pack around information about the units that a value are in and perform checks in them along side every operation. On the other hand, the compile time versions requiter that the units of the values be known at compile time and can't deal with the case where they come from run-time input.

对于S.O.来说，这不是一个好问题(这不是一个特定的编程问题)，但总的来说，这不是一个坏问题。

如果您认为这是微不足道的:那么读时与编译时的区别是什么呢?什么时候这是一个有用的区别?编译器在运行时可用的语言呢?Guy Steele(不是笨蛋，他)在CLTL2中写了7页关于EVAL-WHEN的内容，CL程序员可以使用它来控制这一点。两句话只能勉强给出一个定义，而定义本身还远远不够解释。

In general, it's a tough problem that language designers have seemed to try to avoid. They often just say "here's a compiler, it does compile-time things; everything after that is run-time, have fun". C is designed to be simple to implement, not the most flexible environment for computation. When you don't have the compiler available at runtime, or the ability to easily control when an expression is evaluated, you tend to end up with hacks in the language to fake common uses of macros, or users come up with Design Patterns to simulate having more powerful constructs. A simple-to-implement language can definitely be a worthwhile goal, but that doesn't mean it's the end-all-be-all of programming language design. (I don't use EVAL-WHEN much, but I can't imagine life without it.)

关于编译时和运行时的问题空间是巨大的，而且在很大程度上仍未被探索。这并不是说S.O.是进行讨论的正确场所，但我鼓励人们进一步探索这一领域，特别是那些对它应该是什么没有先入为主概念的人。这个问题既不简单也不愚蠢，我们至少可以给检察官指出正确的方向。

不幸的是，我不知道任何好的参考资料。CLTL2稍微讲了一下，但对于学习它并不是很好。