Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > RTTI overhead

Reply
Thread Tools

RTTI overhead

 
 
Agoston Bejo
Guest
Posts: n/a
 
      01-05-2005
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


 
Reply With Quote
 
 
 
 
Ron Natalie
Guest
Posts: n/a
 
      01-05-2005
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.
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      01-05-2005
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
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      01-05-2005
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.

 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      01-05-2005
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
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      01-05-2005
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.

 
Reply With Quote
 
Ron Natalie
Guest
Posts: n/a
 
      01-05-2005
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.
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      01-05-2005
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.

 
Reply With Quote
 
Agoston Bejo
Guest
Posts: n/a
 
      01-06-2005
"Ioannis Vranos" <(E-Mail Removed)> 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.



 
Reply With Quote
 
Mike Hewson
Guest
Posts: n/a
 
      01-06-2005
Agoston Bejo wrote:
> "Ioannis Vranos" <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[RTTI] cast base class pointer to <templated> derived class pointer tirath C++ 3 10-12-2003 01:44 PM
RTTI versus a base class enum to represent type BillyO C++ 2 09-30-2003 10:21 PM
About RTTI Steven Lien C++ 4 08-19-2003 06:03 PM
Re: RTTI John Harrison C++ 2 07-14-2003 02:36 PM
Re: RTTI Alf P. Steinbach C++ 0 07-14-2003 08:18 AM



Advertisments