{"id":25640,"date":"2020-03-02T15:07:18","date_gmt":"2020-03-02T15:07:18","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=25640"},"modified":"2020-03-02T15:10:02","modified_gmt":"2020-03-02T15:10:02","slug":"the-performance-benefits-of-final-classes","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/the-performance-benefits-of-final-classes\/","title":{"rendered":"The Performance Benefits of Final Classes"},"content":{"rendered":"

The final <\/code><\/span>specifier<\/span> in C++<\/span> marks a <\/span>class <\/span>or virtual member function <\/span>as one which cannot be derived from<\/span> or <\/span>overriden<\/span>. For example, consider the following code:<\/span>\u00a0<\/span><\/p>\n

\u00a0struct base {\u00a0\r\n\u00a0 virtual void f() const = 0;\u00a0\r\n};\u00a0\r\n\u00a0\r\nstruct derived final : base {\u00a0\r\n\u00a0 void f() const override {}\u00a0\r\n};<\/pre>\n
If we attempt to write a new class which derives from `derived` then we get a compiler error:<\/span>\u00a0<\/span><\/p>\n
struct oh_no : derived {\u00a0\r\n};<\/pre>\n
<source>(9): error C3246: 'oh_no': cannot inherit from 'derived' as it has been declared as 'final'\r\n<source>(5): note: see declaration of 'derived'<\/pre>\n
The final<\/code> <\/span>specifier<\/span> is useful for expressing to readers of the code that a class is not to be derived from and having the compiler enforce this, but it can also improve performance through aiding <\/span>devirtualization<\/span><\/i>.<\/span>\u00a0<\/span><\/p>\n
Devirtualization<\/span>\u00a0<\/span><\/h2>\n
Virtual functions require an indirect call through the <\/span>vtable<\/span>, which is more expensive than a direct call<\/span> due to <\/span>interactions with <\/span>branch prediction and <\/span>the instruction cache, <\/span>and also <\/span>the prevention of <\/span>further optimizations which could be <\/span>carried out after<\/span> inlining<\/span> the<\/span> call<\/span>.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n
Devirtualization<\/span> is a compiler optimization which attempts to resolve virtual function calls at compile time rather than runtime. <\/span>This<\/span> eliminates <\/span>all<\/span> the <\/span>issues <\/span>noted above, <\/span>so <\/span>it <\/span>can<\/span> greatly improve the performance of code which uses many virtual calls<\/span>1<\/span><\/sup>.<\/span>\u00a0<\/span><\/p>\n
Here is a minimal example of <\/span>devirtualization<\/span>:<\/span>\u00a0<\/span><\/p>\n
struct dog {\u00a0\r\n\u00a0 virtual void speak() {\u00a0\r\n\u00a0\u00a0\u00a0 std::cout << \"woof\";\u00a0\r\n\u00a0 }\u00a0\r\n};\u00a0\r\n\r\n\r\nint main() {\u00a0\r\n\u00a0 dog fido;\u00a0\r\n\u00a0 fido.speak();\u00a0\r\n}<\/pre>\n
In this code, even though <\/span>dog::<\/span><\/code>speak<\/code> is a virtual function, the only possible result of main<\/code> is to output \u201dwoof\u201d<\/code><\/span>. If you look at the <\/span>compiler output<\/span><\/a> you\u2019ll see that MSVC, GCC, and Clang all recognize this and inline the definition of dog::speak<\/code> into main<\/code>, avoiding the need for a<\/span>n indirect<\/span> call.<\/span>\u00a0<\/span><\/p>\n
The Benefit of <\/span>f<\/span>inal<\/span><\/code>\u00a0<\/span><\/h2>\n
The final<\/code> <\/span>specifier<\/span> can provide the compiler with more opportunities for <\/span>devirtualization<\/span> by helping it identify more cases where virtual calls can be resolved at compile time. Coming back to our original example:<\/span>\u00a0<\/span><\/p>\n
struct base {\u00a0\r\n\u00a0 virtual void f() const = 0;\u00a0\r\n};\u00a0\r\n\u00a0\r\nstruct derived final : base {\u00a0\r\n\u00a0 void f() const override {}\u00a0\r\n};<\/pre>\n
Consider this function:<\/span>\u00a0<\/span><\/p>\n
void call_f(derived const& d) {\u00a0\r\n\u00a0 d.f();\u00a0\r\n}<\/pre>\n
Since derived<\/code> is marked final<\/code><\/span> the compiler knows it cannot be derived from further<\/span>. This means that the call to f<\/code> will only ever call <\/span>derived::<\/span><\/code>f<\/code>, so the call can be resolved at compile time. As proof, here is the compiler output for call_f<\/code> on MSVC when derived<\/code> or <\/span>derived::<\/span><\/code>f<\/code> are marked as final<\/code>:<\/span>\u00a0<\/span><\/p>\n
ret 0\u00a0\r\n<\/pre>\n
You can see that the <\/span>derived::<\/span><\/code>f<\/code> has been <\/span>inlined<\/span> into the definition of <\/span>call_f<\/span><\/code>. If we were to take the final<\/code> specifier off the definition, the<\/span> assembly would look<\/span> like this:<\/span>\u00a0<\/span><\/p>\n
mov rax, QWORD PTR [rcx]\u00a0\r\nrex_jmp QWORD PTR [rax]<\/pre>\n
This code loads the <\/span>vtable<\/span> from d<\/code>, then makes an indirect call to <\/span>derived::<\/span><\/code>f<\/code> through the function pointer stored at the relevant location.<\/span>\u00a0<\/span><\/p>\n
The cost of a pointer load and jump may not <\/span>look<\/span> like<\/span> much<\/span> since it\u2019s just two instructions, but remember that this may involve a branch misprediction and\/or instruction cache miss, which would result in a pipeline stall. Furthermore, if there was more code in <\/span>call_f<\/span><\/code> or functions which call it, the compiler may be able to optimize it much more aggressively given the full visibility of the code which will be executed and the additional analysis which this enables.<\/span>\u00a0<\/span><\/p>\n
Conclusion<\/span>\u00a0<\/span><\/h2>\n
Marking your classes or member functions as final<\/code> <\/span>can improve<\/span> the performance of your code by giving the compiler more opportunities to resolve virtual calls at compile time.<\/span>\u00a0<\/span><\/p>\n
Consider if there are any places in your codebases which would benefit from this and measure the impact!<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n
 <\/p>\n
1<\/span> http:\/\/assemblyrequired.crashworks.org\/how-slow-are-virtual-functions-really\/<\/span><\/a>\u00a0<\/span><\/p>\n
\u00a0 <\/span>https:\/\/sites.cs.ucsb.edu\/~urs\/oocsb\/papers\/oopsla96.pdf<\/span><\/a>\u00a0<\/span><\/p>\n
\u00a0 <\/span>https:\/\/stackoverflow.com\/questions\/449827\/virtual-functions-and-performance-c<\/span><\/a>\u00a0<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
The final specifier in C++ marks a class or virtual member function as one which cannot be derived from or overriden. For example, consider the following code:\u00a0 \u00a0struct base {\u00a0 \u00a0 virtual void f() const = 0;\u00a0 };\u00a0 \u00a0 struct derived final : base {\u00a0 \u00a0 void f() const override {}\u00a0 }; If we attempt […]<\/p>\n","protected":false},"author":706,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,512],"tags":[],"class_list":["post-25640","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","category-general-cpp-series"],"acf":[],"blog_post_summary":"
The final specifier in C++ marks a class or virtual member function as one which cannot be derived from or overriden. For example, consider the following code:\u00a0 \u00a0struct base {\u00a0 \u00a0 virtual void f() const = 0;\u00a0 };\u00a0 \u00a0 struct derived final : base {\u00a0 \u00a0 void f() const override {}\u00a0 }; If we attempt […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/25640","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/706"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=25640"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/25640\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=25640"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=25640"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=25640"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}