Runtime vs Compile time

Question

Can anyone please give me a good understanding of whats the difference between run-time and compile-time?

Answer 1

Compile-time: the time period in which you, the developer, are compiling your code.

Run-time: the time period which a user is running your piece of software.

Do you need any clearer definition?

Answer 2

Hmm, ok well, runtime is used to describe something that occurs when a program is running.

Compile time is used to describe something that occurs when a program is being built (usually, by a compiler).

Answer 3

Run time means something happens when you run the program.

Compile time means something happens when you compile the program.

Answer 4

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 5

For example: In a strongly typed language, a type could be checked at compile time or at runtime. At compile time it means, that the compiler complains if the types are not compatible. At runtime means, that you can compile your program just fine but at runtime, it throws an exception.

Answer 6

(edit: the following applies to C# and similar, strongly-typed programming languages. I'm not sure if this helps you).

For example, the following error will be detected by the compiler (at compile time) before you run a program and will result in a compilation error:

int i = "string"; --> error at compile-time

On the other hand, an error like the following can not be detected by the compiler. You will receive an error/exception at run-time (when the program is run).

Hashtable ht = new Hashtable();
ht.Add("key", "string");
// the compiler does not know what is stored in the hashtable
// under the key "key"
int i = (int)ht["key"];  // --> exception at run-time

Answer 7

I think of it in terms of errors, and when they can be caught.

Compile time:

string my_value = Console.ReadLine();
int i = my_value;

An int can't be assigned a string value, so the compiler can know for sure that this code has a problem, i.e. it can be caught at compile time

Run time:

string my_value = Console.ReadLine();
int i = int.Parse(my_value);

Here the outcome depends on the value that was given by the user, some values can be parsed to an int, others can't i.e. it can only be caught at run time

Answer 8

Compile Time:

Things that are done at compile time incur (almost) no cost when the program is run but might incur a lot of cost when you build the program.

Run Time:

More or less the exact opposite. Little cost at when you build, more cost when the program is run.

From the other side; If it is compile time it runs only on your machine and only if it is run time will it run on your users machine.

Relevance

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.

Answer 9

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. Of 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
   • Deferencing 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 10

It's not a good question for S.O. (it's not a specific programming question), but it's not a bad question in general.

If you think it's trivial: what about read-time vs compile-time, and when is this a useful distinction to make? What about languages where the compiler is available at runtime? Guy Steele (no dummy, he) wrote 7 pages in CLTL2 about EVAL-WHEN, which CL programmers can use to control this. 2 sentences are barely enough for a definition, which itself is far short of an explanation.

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.)

And the problemspace around compile-time and run-time is huge and still largely unexplored. That's not to say S.O. is the right place to have the discussion, but I encourage people to explore this territory further, especially those who have no preconceived notions of what it should be. The question is neither simple nor silly, and we could at least point the inquisitor in the right direction.

Unfortunately, I don't know any good references on this. CLTL2 talks about it a bit, but it's not great for learning about it.

Answer 11

Translation of source code into stuff-happening-on-the-[screen|disk|network] can occur in (roughly) two ways; call them compiling and interpreting.

In a compiled program (examples are c and fortran):

1. The source code is fed into another program (usually called a compiler--go figure), which produces an executable program (or an error).
2. The executable is run (by double clicking it, or typing it's name on the command line)

Things that happen in the first step are said to happen at "compile time", things that happen in the second step are said to happen at "run time".

In an interpreted program (example MicroSoft basic (on dos) and python (I think)):

1. The source code is fed into another program (usually called an interpreter) which "runs" it directly. Here the interpreter serves as an intermediate layer between your program and the operating system (or the hardware in really simple computers).

In this case the difference between compile time and run time is rather harder to pin down, and much less relevant to the programmer or user.

Java is a sort of hybrid, where the code is compiled to bytecode, which then runs on a virtual machine which is usually an interpreter for the bytecode.

There is also an intermediate case in which the program is compiled to bytecode and run immediately (as in awk or perl).