A howl on the wind…

C++ 14 Apr 2010 20:41:21

C++ dynamic_cast Performance

Comments (9)

9 Responses to “C++ dynamic_cast Performance”

1. on 16 Apr 2010 at 14:53:31 1.Jorn said …

   It would be nice to see windows tested on a comparable machine

2. on 16 Apr 2010 at 18:12:56 2.Tino Didriksen said …

   I agree, but that would be a lot of extra work…

   Right now, I can develop and run the tests simultaneously on my own Windows computer and via SSH on the Linux machine. Having to reboot to Linux just to re-run the tests would be painful. There is also the Cygwin or MinGW options, but while they are nice they really cannot be called a representative picture of how g++ performs.

   Plus, the tests I do are not about compiler vs. compiler; they’re about general methods and which ones reliably perform well cross-platform.

3. on 01 Oct 2010 at 17:06:19 3.Steven Lubars said …

   Although to be avoided when possible, applications sometimes need to perform explicit RTTI. Several techniques exist to improve upon the performance of using dynamic_cast for this purpose:

   1) Wite a wrapper around type_info that allows comparison, assignment, etc. (see Alexandrescu).

   2) I recently encountered another technique at http://ciaranm.wordpress.com/2010/05/24/runtime-type-checking-in-c-without-rtti/ that assigns a unique integer to each type:

   
#include <iostream>
using namespace std;

   short TypeId() {
       static short typeId = 0;
       return typeId++;
   }

   template <typename T>
   short TypeId() {
       static short typeId = TypeId();
       return typeId;
   }

   int main() {
    cout << TypeId<int>() << endl;
    cout << TypeId<short>() << endl;
    cout << TypeId<float>() << endl;
    cout << TypeId<int>() << endl;
}


0
1
2
0


   Of course this works for complex types as well.

   I think it would be interesting to compare the performance of these techniques to dynamic_cast for the purpose of explicit RTTI.

4. on 27 Oct 2010 at 09:16:25 4.Cyril said …

   I think it is worth noting that reinterpret_cast is a null-cost operation from the CPU point of view since it does not translate to any actual machine code after compilation. What you measure here is the cost of the benchmark loop itself as well as the call to getType(), which you don’t need to do if you know the actual type of the object.
   Where did I lose the point?

5. on 27 Oct 2010 at 13:43:04 5.Tino Didriksen said …

   Part of the point was that it is much much faster to code around dynamic_cast any way you can, including designing the program so that you will always know the type.

   So you did not lose the point. This is just to show new coders how horribly slow dynamic_cast is and why they should design to avoid it.

6. on 27 Oct 2010 at 13:52:08 6.Cyril said …

   Indeed.
   Looks like on MSVC, dynamic_casts are implemented with ugly recursive strcmps. Btw, Qt users should always resort to qobject_cast instead, which only does a pointer comparison by inheritance level.

   Thanks for your answer and your nice article!

7. on 08 Jun 2018 at 07:35:38 7.Martin said …

   Just one little thing: in this context reinterpret_cast is a recipe for disaster.

   Try it with multiple inheritance and you’ll see what I mean ;-)

   I bet that static_cast has the same performance in simple cases and just makes an ADD or SUB when multiple inheritance is involved.

8. on 08 Apr 2020 at 05:24:54 8.freealibi said …

   I only have one simple question: is fat pointer destined to be faster than dynamic_cast?

   The context is that one project I was told to maintain has this 16 lines of switch..case to determine the real type of a fat pointer.

   Given that dynamic_cast can only incur one (L3 maybe?) cache miss, and this 16 lines of switch..case function may as well cause at least L1i$ miss, maybe the performance is neglectable somehow?

   Also maintaining 16 lines of switch..case is a pain in the ass. I might just use dynamic_cast instead no matter what.

9. on 05 Jun 2024 at 01:52:45 9.Mateusz Płóciennik said …

   I have rewritten `speed_dynamic_cast.cpp` using Google Benchmark.
   See: https://quick-bench.com/q/AFFjW622BSd4Zd1HqQXpB-2bdok

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

Anti-spam word: (Required)*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.

Δ