Reputation: 303
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.
Upvotes: 1
Views: 441
Reputation: 5176
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.
Upvotes: 4