RTTI overhead

[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

[Ron Natalie]

Agoston Bejo wrote:

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.

[Victor Bazarov]

Agoston Bejo wrote:

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

[Rolf Magnus]

Agoston Bejo wrote:

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.

[Ioannis Vranos]

Agoston Bejo wrote:

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.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Rolf Magnus]

Ioannis Vranos wrote:

Agoston Bejo wrote:

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

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.

[Ron Natalie]

Rolf Magnus wrote:

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.

[Rolf Magnus]

Victor Bazarov wrote:

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.

[Agoston Bejo]

"Ioannis Vranos" <iv*@remove.this.grad.com> az alábbiakat írta a következo
hírüzenetben: 1104955152.262790@athnrd02...

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.

[Mike Hewson]

Agoston Bejo wrote:

"Ioannis Vranos" <iv*@remove.this.grad.com> az alábbiakat írta a következo

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

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

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal