Re: Why is dynamic_cast so dam slow?

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> 1) Why is it so slow?

It needs to walk the entire class hierarchy, potentially dealing with
the following issues:
- multiple inheritance, and adjustment of the pointer by offsets
- virtual inheritance, and finding the vbase pointer inside the object
- ambiguities (i.e multiple appearances of the same base in an object)
  need to produce a failure. That means that the entire class hierarchy
  must be traversed
- access control (conversion to private bases) needs to lead to
  failures. Therefore, private and protected inheritance must be
  available at run time as well.

I don't know whether that justifies it being "so" slow, as that is a
relative judgement.

> 2) Why does there even need to be a function call for dynamic_cast. 
> Can't gcc get the relevant information from looking at the vtables in an
> inline function.

No.

Or: make a proposal. Also, I doubt that the function calls make it
slow.  Please note that there are virtual calls involved as well,
which specialize the "simple" cases for speed (i.e. single inheritance).

> 3) Will this be improved with the new API.

The ABI itself is not slow or fast; implementations of it are.  I
think it has provisions for some speed improvements (e.g. vtable
points directly to type information, instead of to a function
returning type information).

> Thanks again.  For now I solved the problem by storing the necessary
> information directly in the base object and simply checking with it and
> then doing a static_cast instead of calling a dynamic_cast.  My program
> ran a good 20% faster by eliminating the time consuming dynamic_casts.

IMHO, if you have to convert to derived classes frequently and in many
places, something is wrong with the application design. This is of
course off-topic, here.

Regards,
Martin