Do you realize that you just made an argument why it is important for the destructor to be virtual ? If the compiler doesn't know the exact type (and thus can't inline the call), there is a serious risk that any derived destructor might need to be executed, but the compiler doesn't know that (and neither does the runtime, as there is no entry for the destructor in the vtable). It doesn't matter whether the base-class destructor is a no-op. What matters is what is in the derived class destructor, which you (or the base class implementor) does not have any control over.
I clearly understand the reason why the destructor of polymorphic types should be declared virtual. I was trying to make an argument against polymorphism in general, because it produces much greater runtime overhead than most people seem to appreciate when used on simple types that should be heavily inlined. In fact, I don't myself understand the reason Emil has for not declaring the destructor virtual in this case. He said he didn't care about overhead, after all. I was simply pointing out that the overhead is greater than what Hartmut suggested. So great, in fact, that I prefer to avoid polymorphic programming style for that very reason. Thanks, Luke