1

In my project we had, 1 user defined default destructor, which was written to follow some coding standard requirements of the project. The Class of this destructor was instantiated more than 200 times, which had increased the overall response time, when this mentioned destructor was removed, I observed improvement in response time by 28 msec. Can anyone explain why this timing difference, though those were default destructors only but defined by users, which anyways will be called by the compiler.

With the usage of "user defined default destructor" I meant a destructor which is empty :

~Classname(){ };

Doing nothing, but is added to fulfill project's standards.

Just to add more clarity, this destructor doesn't fall in following categories:

1.Destructors declared as 'virtual'.

2.The destructors of static and singleton classes.

3.The destructors of the classes whose objects created using the 'new' keyword.

4.The destructors of the classes whose objects deleted using the 'delete' keyword.

Arti
  • 293
  • 2
  • 3
  • 10
  • 6
    Can you show us the code for this destructor? – user7116 Apr 24 '12 at 17:51
  • 2
    I would suspect that the destructor was declared virtual. – andre Apr 24 '12 at 17:53
  • 5
    And be a bit more specific. "user defined default destructor" is an oxymoron. – smocking Apr 24 '12 at 17:53
  • the destructor is empty : ~Classname(){ }; and the destructor is not virtual. – Arti Apr 24 '12 at 18:02
  • here the default means there was nothing to do just to have process in place. that resulted into increase in execution time. – Arti Apr 24 '12 at 18:05
  • 3
    [Related](http://connect.microsoft.com/VisualStudio/feedback/details/560640/empty-c-destructors-prevent-optimization). I believe that to be an issue of the compiler, but I have heard this before of different compilers... even though I fail to see why the compiler would not be able to generate exactly the same code. – David Rodríguez - dribeas Apr 24 '12 at 18:10
  • @Arti: You should add sample code to the question so that it is self-contained (i.e. readers are not forced to read into the comments to understand exactly what you mean) – David Rodríguez - dribeas Apr 24 '12 at 18:13
  • @DavidRodríguez-dribeas, is this increase in response time due to, compiler overriding its default destructors, with the user defined empty destructors? – Arti Apr 24 '12 at 18:15
  • @Arti: No, override implies virtual functions and inheritance. In that case (the Visual Studio bug report) the issue is related to exception. The compiler is able to optimize more on the assumption that the compiler generated destructor will not throw, but it is not realizing that the equivalent user defined destructor has exactly the same properties. – David Rodríguez - dribeas Apr 24 '12 at 18:25
  • @Arti: There are several other details that would be useful to know. Does the class have a base class? A virtual base class? Does the base class have a virtual dtor? Does the class have member variables that have destructors? Is your destructor defined inline? – leedm777 Apr 24 '12 at 18:39
  • @dave, This itself is a base class, which is derived by no. of classes. It does not have any virtual destructor. It does not have member variables, that have destructors. No the destructor is not defined inline. – Arti Apr 24 '12 at 18:44
  • If the destructor is (explicitly or implicitly) inline, then this is a bug in your compiler's optimizer. Try another compiler. – n. m. could be an AI Apr 24 '12 at 18:47
  • *This itself is a base class, which is derived by no. of classes. It does not have any virtual destructor.* — This *is* a potential problem. – n. m. could be an AI Apr 24 '12 at 18:48
  • @n.m. I am sorry for the above mentioned comment, it is getting instantiated many times not derived. – Arti Apr 24 '12 at 18:53
  • Ok so no problem here. But why not inline? – n. m. could be an AI Apr 24 '12 at 18:54
  • @n.m. even I have observed timing improvement(though less) after removing inline empty destructors as well.. – Arti Apr 24 '12 at 18:57

1 Answers1

5

I've encountered several places where compilers don't recognize empty destructors correctly

  • MSVC cannot inline functions if they return objects that have user defined destructors, even if that destructor is empty.

  • Type traits like is_trivial, is_pod etc. don't work the way you would want with empty destructors, on any compilers that I've tested. That may change how some algorithms or containers are implemented for specific types.

  • User defined destructors may change the exception handling code because the compiler has to create code for unwinding the stack. Again, if I remember correctly MSVC doesn't recognize empty destructors correctly for this purpose either.

  • Every allocation you do with new T[] has to allocate extra space for item count if T has non-trivial destructor. Also, that can change the alignment of the memory block which can really hurt performance. Neither MSVC or g++ optimize this correctly for empty destructors.

Timo
  • 5,125
  • 3
  • 23
  • 29