Runtime vs. Compile time

Question

What is the difference between run-time and compile-time?

Answer 1

Basically if your compiler can work out what you mean or what a value is "at compile time" it can hardcode this into the runtime code. Obviously if your runtime code has to do a calculation every time it will run slower, so if you can determine something at compile time it is much better.

Eg.

Constant folding:

If I write:

int i = 2;
i += MY_CONSTANT;

The compiler can perform this calulation at compile time because it knows what 2 is, and what MY_CONSTANT is. As such it saves itself from performing a calculation every single execution.

Answer 2

The difference between compile time and run time is an example of what pointy-headed theorists call the phase distinction. It is one of the hardest concepts to learn, especially for people without much background in programming languages. To approach this problem, I find it helpful to ask

1. What invariants does the program satisfy?
2. What can go wrong in this phase?
3. If the phase succeeds, what are the postconditions (what do we know)?
4. What are the inputs and outputs, if any?

Compile time

1. The program need not satisfy any invariants. In fact, it needn't be a well-formed program at all. You could feed this HTML to the compiler and watch it barf...
2. What can go wrong at compile time:
   • Syntax errors
   • Typechecking errors
   • (Rarely) compiler crashes
3. If the compiler succeeds, what do we know?
   • The program was well formed---a meaningful program in whatever language.
   • It's possible to start running the program. (The program might fail immediately, but at least we can try.)
4. What are the inputs and outputs?
   • Input was the program being compiled, plus any header files, interfaces, libraries, or other voodoo that it needed to import in order to get compiled.
   • Output is hopefully assembly code or relocatable object code or even an executable program. Or if something goes wrong, output is a bunch of error messages.

Run time

1. We know nothing about the program's invariants---they are whatever the programmer put in. Run-time invariants are rarely enforced by the compiler alone; it needs help from the programmer.

2. What can go wrong are run-time errors:

   • Division by zero
   • Dereferencing a null pointer
   • Running out of memory

   Also there can be errors that are detected by the program itself:

   • Trying to open a file that isn't there
   • Trying find a web page and discovering that an alleged URL is not well formed
3. If run-time succeeds, the program finishes (or keeps going) without crashing.
4. Inputs and outputs are entirely up to the programmer. Files, windows on the screen, network packets, jobs sent to the printer, you name it. If the program launches missiles, that's an output, and it happens only at run time :-)

Answer 3

You can understand the code compile structure from reading the actual code. Run-time structure are not clear unless you understand the pattern that was used.