Why is dynamic_cast so dam slow?
Martin v. Loewis
martin@loewis.home.cs.tu-berlin.de
Fri Dec 31 23:54:00 GMT 1999
> 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
More information about the Gcc
mailing list