virtual destructor performance

Question

Possible Duplicate:
Virtual functions and performance - C++

I have some class:

class I
{
public:
  virtual void foo() = 0;
protected:
  virtual ~I(){}
};

This class does not provide interface for instance deletion, so making destructor protected is quite logical solution. For this reason it is unnecessary to make the destructor virtual. But I have code where it is made virtual.

It doesn't look like a big mistake, but is it significantly for the code perfomance? When we create virtual function we add one more record to the virtual function table and when we make virtual call we search in this table. So it means that looking up time increases. Am I right?

The overhead of a vcall really is pretty small. It's not like a big table lookup -- it's just another pointer de-reference. So deleting just a single instance of it here or there, the overhead of the vcall will be negligible. If it happens in a tight loop, then you *may* care - but at that point the only way to know is to benchmark it. — Jonathon Reinhart, Jan 06 '13 at 21:22
You only do an once table lookup if the call is in a polymorphic context. It doesn't sound like that's the case here, so there should be no indirection. — Oliver Charlesworth, Jan 06 '13 at 21:23

score 5 · Accepted Answer · answered Jan 06 '13 at 21:22

Even if this were an issue (which it isn't), no, it wouldn't add time. Lookup isn't the runtime actually looking up anything - it doesn't matter how big the vftable is. It knows exactly where to jump within the table.

So - there is some cost to calling a virtual method - there's no cost to the actual look-up.

score 3 · Answer 2 · answered Jan 06 '13 at 21:24

In general you should always declare the destructor as virtual when working with polymorphic classes. Otherwise you will end up in the classic problem of:

Base *derived = new Derived();
delete derived;

The worries about performance are surely irrelevant compared to having a potential problem in your code. Today you don't need to delete the object, maybe tomorrow you will and if you forget about this you'll end up generating subtle bugs.

The cost of a virtual invocation exists but it is nothing you should never ever worry about unless calling millions of virtual methods per second.

While a lookup of a method in a vtable is not a runtime operation, it's a compile time operation. Once compiled your code already knows which index of the vtable is occupied by the specified method. The time spent is the indirection of obtaining the address of the function from the vtable.

score 0 · Answer 3 · answered Jan 06 '13 at 23:16

0

Good answers. The cost of a virtual function call is like one hair on an ape.

However, destructors in general can be slow, virtual or not, because it is really easy to over-complicate your data and class structure, so when you delete something, it can run through 27 meters of software that you didn't even realize it was doing.

answered Jan 06 '13 at 23:16

Mike Dunlavey

40,059
14
91
135

yes but if you patient enough you can make an ape bold.. by pulling hairs one by one. you can also have a team of ape hair pullers to help.. – Boppity Bop Apr 04 '22 at 16:18

virtual destructor performance

3 Answers3