Compiler overhead ?

[mattheweston]

We've had several discussions here about various areas where overhead can creep into a program. I'd like to propose the following questions to the community.

What types of overhead can you get from various compilers?
Are there benefits to using Visual Studio to compile your code versus gcc or g++ ?
Is there a prefered or best compiler to use to minimize overhead?

Are there flags/options that can be set for a given compiler that can minimize overhead?

For the sake of this discussion we will assume that your code is fully optimized and has minimal to no overhead in order to focus solely on the compliers.

[bbguimaraes]

A compiler translates your code to machine language code. That might seem simple, but it's not. You can argue that the job of the compiler (or, better, the compiler's programmers) in translating your code to machine code is comparable to your job in writing code. In this way, the code the compiler generates is as good as it was programmed.

Translating code isn't the only thing a compiler does, at least not literal tanslation. Optimization is a critical part of compilation. Think about the (recurring) code below:

Code: Select all

vector<int> v;
// ...
for(int i = 0; i < v.size(); ++i)
    ++v[i];

It is a common programming structure: iterate over a vector. The problem with this code is the loop's terminating condition. It gets evaluated at every iteration, but the value of the expression on the right side doesn't change during the execution. This is a simple example of optimization, and yet, not all compilers do it. Code optimization is very complex and compiler support for the different kinds varies a lot.

One more aspect is platform-specific code. Compilers developed for specific platforms usualy use platform-specific operations. memcpy is a typical example. Many compilers use a OS/hardware optimized version of it.

[Falco Girgis]

I don't think you're asking the right question.

There is always going to be overhead associated with programming languages that are above the machine level. The higher level the language, the higher the overhead. This isn't a "fault" of the compiler. This is just the nature of abstraction in computing.

I think what you SHOULD be asking are what specific "mechanisms" within specific programming languages produce overhead. Overhead isn't something you incur by the accident of incompetent compilers--it is by your design decisions as a developer. For example, some overhead associated with C++:

1) RTTI and dynamic_cast
2) virtual function invokation and vtables
3) exceptions
4) templates

and so on... Would you like to rephrase your question?

[mattheweston]

So compilers don't introduce new overhead they just compile the overhead that is already there in the code.

[wtetzner]

For example, some overhead associated with C++:

1) RTTI and dynamic_cast
2) virtual function invokation and vtables
3) exceptions
4) templates

and so on... Would you like to rephrase your question?

Just out of curiosity, what runtime overhead is incurred by using templates?

Code size might increase, although templated functions will only be expanded for a type if there is an invocation at that type. So it's not clear that it's introducing overhead, since you'd have needed to write that code one way or another.

[Falco Girgis]

For example, some overhead associated with C++:

1) RTTI and dynamic_cast
2) virtual function invokation and vtables
3) exceptions
4) templates

and so on... Would you like to rephrase your question?

Just out of curiosity, what runtime overhead is incurred by using templates?

Code size might increase, although templated functions will only be expanded for a type if there is an invocation at that type. So it's not clear that it's introducing overhead, since you'd have needed to write that code one way or another.

It's size overhead, as you said, but I disagree with it not being clear about overhead introduction.

I don't know many people who would literally copy and paste the same functions and classes to achieve the same thing with different types. I think almost anybody would construct a heirarchial relationship to reuse commonality with runtime polymorphism.

[wtetzner]

I don't know many people who would literally copy and paste the same functions and classes to achieve the same thing with different types. I think almost anybody would construct a heirarchial relationship to reuse commonality with runtime polymorphism.

That's fair.

As is often the case, you end up having a trade-off between size and speed.