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

Compile Time:

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

Run-Time:

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

From the other side; If something is done at compile time, it runs only on your machine and if something is run-time, 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. 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.

Answer 3

Compile time: Time taken to convert the source code into a machine code so that it becomes an executable is called compile time.

Run time: When an application is running, it is called run time.

Compile time errors are those syntax errors, missing file reference errors. Runtime errors happen after the source code has been compiled into an executable program and while the program is running. Examples are program crashes, unexpected program behavior or features don't work.

Answer 4

I have always thought of it relative to program processing overhead and how it affects preformance as previously stated. A simple example would be, either defining the absolute memory required for my object in code or not.

A defined boolean takes x memory this is then in the compiled program and cannot be changed. When the program runs it knows exactly how much memory to allocate for x.

On the other hand if I just define a generic object type (i.e. kind of a undefined place holder or maybe a pointer to some giant blob) the actual memory required for my object is not known until the program is run and I assign something to it, thus it then must be evaluated and memory allocation, etc. will be then handled dynamically at run time (more run time overhead).

How it is dynamically handled would then depend on the language, the compiler, the OS, your code, etc.

On that note however it would really depends on the context in which you are using run time vs compile time.

Answer 5

The major difference between run-time and compile time is:

1. If there are any syntax errors and type checks in your code,then it throws compile time error, where-as run-time:it checks after executing the code. For example:

int a = 1 int b = a/0;

here first line doesn't have a semi-colon at the end---> compile time error after executing the program while performing operation b, result is infinite---> run-time error.

2. Compile time doesn't look for output of functionality provided by your code, whereas run-time does.

Answer 6

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.