what is the performance cost of using runtime type information (RTTI)?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hey all,

I know that dynamic_cast<> takes some time, but , for instance, is there a memoy cost associated in with it? Does it have to maintain a table in memory, thus bloating the runtime ram needs of my dll? Does it bloat the actual download size - would my dll be smaller without it?

thanks - I'm using rtti in some instances, but I jsut want to know if it's costing me hundreds of K in extra download.

-denny-
 
denny said:
Hey all,

I know that dynamic_cast<> takes some time, but , for instance, is
there a memoy cost associated in with it? Does it have to maintain a
table in memory, thus bloating the runtime ram needs of my dll? Does
it bloat the actual download size - would my dll be smaller without
it?

thanks - I'm using rtti in some instances, but I jsut want to know if
it's costing me hundreds of K in extra download.
Click to expand...

Yes, there is a memory cost associated with RTTI - that (and backward
compatibility) is why there's a compiler option to turn RTTI support on and
off.

Each class that has at least one virtual function that's compiled with /GR
(enable RTTI) will include some "meta-data" that describes the class and
it's ancestry. Typically this data in on the order of a few 10's of bytes
per class, but grows linearly with the length of the class names, and
linearly with the depth of the inheritance graph.

Your DLL would be smaller without RTTI, since the overhead data is all
static initialized data emitted by the compiler. You might try building
your DLL with and without /GR to see if the size difference is significant
in your application. For most applications, it's not a significant amount
of overhead, but clearly that depends on how many classes with virtual
functions you have, and how complex your inheritance hierarchies are.

-cd
 
Back
Top