RTTI overhead

A

Agoston Bejo

Hello there,
I would like to know what overheads there are to think of when using RTTI. I
understand that enabling RTTI increases the sizes of the classes, but not
the objects themselves. This doesn't sound too bad.
What I'm worried about is whether there is a general performance overhead
caused by enabling RTTI, such as enabling exceptions makes a C++ program
slower even when there are no exceptions actually used.
Are there similar considerations in the case of RTTI?

I am using VC++7.1, but I'm also interested about this in general.

Thx, Agoston
 
R

Ron Natalie

Agoston said:
Hello there,
I would like to know what overheads there are to think of when using RTTI. I
understand that enabling RTTI increases the sizes of the classes, but not
the objects themselves. This doesn't sound too bad.

Polymorphic objects (those with virtual functions) are slightly larger
typically because they contain a pointer to the class specific information
(vtable pointer).
What I'm worried about is whether there is a general performance overhead
caused by enabling RTTI, such as enabling exceptions makes a C++ program
slower even when there are no exceptions actually used.
Are there similar considerations in the case of RTTI?
As far as C++ is concerned there is no such thing as turning RTTI off.
This is a defect in your compiler. And boy if you ever access a function
requiring RTTI you'll blow up at runtime (believe me I know).

C++ is very careful NOT to incur performance hits on features you are't
using, so if you have a non-polymorphic class (no virtual functions), then
the overhead disappears. Once you have a virtual function, which really
needs the overhead to work, then all the other RTTI-related features like
dynamic cast and dynamic typeid will work with that class.
 
V

Victor Bazarov

Agoston said:
I would like to know what overheads there are to think of when using RTTI. I
understand that enabling RTTI increases the sizes of the classes, but not
the objects themselves. This doesn't sound too bad.
What I'm worried about is whether there is a general performance overhead
caused by enabling RTTI, such as enabling exceptions makes a C++ program
slower even when there are no exceptions actually used.
Are there similar considerations in the case of RTTI?

I am using VC++7.1, but I'm also interested about this in general.

If you can create two programs where one _uses_ RTTI and the other does
not, and otherwise they are _absolutely_ the same, then you can measure
the _real_ overhead. However, logically, that's impossible. If your code
does not use RTTI, why enable RTTI? If after you enable RTTI in your
program that does not use it you notice that it's slower, the you've
created something to measure, but what value does that measurement have?

Also, keep in mind, such overheads cannot be made generic, since they
depend greatly on the compiler/platform/libraries used. If I somehow
measure the "overhead" of using RTTI in my program/compiler combination,
what knowledge can you derive from that for your program/compiler
combination?

See my point?

Victor
 
R

Rolf Magnus

Agoston said:
Hello there,
I would like to know what overheads there are to think of when using RTTI.
I understand that enabling RTTI increases the sizes of the classes, but
not the objects themselves. This doesn't sound too bad.
What I'm worried about is whether there is a general performance overhead
caused by enabling RTTI, such as enabling exceptions makes a C++ program
slower even when there are no exceptions actually used.
Are there similar considerations in the case of RTTI?

Basically, it depends on the compiler, but usually no, there is no overhead.
 
I

Ioannis Vranos

Agoston said:
Hello there,
I would like to know what overheads there are to think of when using RTTI. I
understand that enabling RTTI increases the sizes of the classes, but not
the objects themselves. This doesn't sound too bad.
What I'm worried about is whether there is a general performance overhead
caused by enabling RTTI, such as enabling exceptions makes a C++ program
slower even when there are no exceptions actually used.
Are there similar considerations in the case of RTTI?


"Enabling" exceptions in nowadays implementations should incur no
overheads (unless an exception is thrown in which case what should be
considered as overhead is not clear).


RTTI means "run-time type identification. That means you have to perform
run-time checks to find the type of an object. These checks are the
overhead.


In C++, there is the rule "what you do not use, you do not pay for". So
if you do not use RTTI you do not pay any run-time checks cost.


Thus the phrase "enable" does not make sense.
 
R

Rolf Magnus

Ioannis said:
"Enabling" exceptions in nowadays implementations should incur no
overheads (unless an exception is thrown in which case what should be
considered as overhead is not clear).

Maybe it shouldn't but often, it does incur an overhead in code size, which
indirectly affects performance through higher cache load.
In C++, there is the rule "what you do not use, you do not pay for". So
if you do not use RTTI you do not pay any run-time checks cost.


Thus the phrase "enable" does not make sense.

Well, if you disable it, you'll get a compiler error if you try to use it,
since it's not enabled. At least that's how gcc does it.
 
R

Ron Natalie

Rolf said:
Well, if you disable it, you'll get a compiler error if you try to use it,
since it's not enabled. At least that's how gcc does it.

Not with visual studio, you get a run-time exception. Real handy.
 
R

Rolf Magnus

Victor said:
If you can create two programs where one _uses_ RTTI and the other does
not, and otherwise they are _absolutely_ the same, then you can measure
the _real_ overhead. However, logically, that's impossible. If your code
does not use RTTI, why enable RTTI?

It's the other way round. If RTTI imposes no overhead, why bother disabling
it and risk potential problems with e.g. libraries your program uses?
If there is a significant difference, it might be worth finding out for each
target compiler and each used library if you can disable RTTI.
 
A

Agoston Bejo

Ioannis Vranos said:
Agoston Bejo wrote:

"Enabling" exceptions in nowadays implementations should incur no
overheads (unless an exception is thrown in which case what should be
considered as overhead is not clear).

To my best knowledge, this is not true. That is the main point. I read that
enabling exceptions gets the compiler to generate additional (additional
compared to exceptional-disabled code) code for implementing unwind
semantics, which does make the program run some 20-40% slower (I don't
remember the exact amount) even if not a single throw statement occurs in
your program. That's why you have the possibility to turn it off, I think.
 
M

Mike Hewson

Agoston said:
To my best knowledge, this is not true. That is the main point. I read that
enabling exceptions gets the compiler to generate additional (additional
compared to exceptional-disabled code) code for implementing unwind
semantics, which does make the program run some 20-40% slower (I don't
remember the exact amount) even if not a single throw statement occurs in
your program. That's why you have the possibility to turn it off, I think.

<musing>

I thought 'overhead' meant time( cycles ) and/or space ( bytes ). If
nothing else thermodynamics prevents something for nothing - information
( = energy ) included. Any 'throw' has to know where it's caught,
directly or otherwise, whatever else happens - stack unwinding,
destructors et al. It's a potential execution path 'to the side' of
one's code. No doubt compilers ( and their writers ) differ in skill as
applied to this. After all the Standard only requires 'as if' behaviour,
not performance per se ( to my knowledge ).

With a compiler enabled for exceptions, I'd be dissapointed with any
overhead if I'd never used catch, throw etc. Having said that, I might
well be implying it sometimes via #includes, libraries ... without
knowing it.

<end musing>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top