Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Performance Impact of C++'s `final` Keyword

16bpp.net

Post reply on HN
Print view View original

221–230 of 385 posts

Re: The Performance Impact of C++'s `final` Keyword

#225

Post by jandrewrogers »

sgerenser wrote: post #182
jandrewrogers wrote: post #123

Earlier quoted context omitted.

In modern C++, macros are a viewed as a code smell because they are strictly worse than alternatives in almost all situations. It is a cultural norm; it is a bit like using "unsafe" in Rust if not strictly required for some trivial case. The C++ language has made a concerted effort to eliminate virtually all use cases for macros since C++11 and replace them with type-safe first-class features in the language. It is a…

But how would one conditionally enable or disable the “final” keyword on class members without a preprocessor macro, even in C++23?

Macros are still useful for conditional compilation, as in this case. They've been sunsetted for anything that looks like code generation, which this isn't. I was more commenting on the reflexive "ick" reaction of the author to the use of macros (even when appropriate) because avoiding them has become so engrained in C++ culture. I'm a macro minimalist but I would use them here.

Many people have a similar reaction to the use of "goto", even though it is absolutely the right choice in some contexts.

Re: The Performance Impact of C++'s `final` Keyword

#226

Post by Maxatar »

koyote wrote: post #209
akoboldfrying wrote: post #188

I would expect "final" to have no effect on this type of code at all. That it does in some cases cause measurable differences I put down to randomly hitting internal compiler thresholds (perhaps one of the inlining heuristics is "Don't inline a function with more than 100 tokens", and the "final" keyword pushes a couple of functions to 101). Why would I expect no performance difference? I haven't looked at the code,…

> (perhaps one of the inlining heuristics is "Don't inline a function with more than 100 tokens", and the "final" keyword pushes a couple of functions to 101). That definitely is one of the heuristics in MSVC++. We have some performance critical code and at one point we noticed a slowdown of around ~4% in a couple of our performance tests. I investigated but the only change to that code base involved fixing up an err…

Since the inlining is performed in MSVC's backend, as opposed to its frontend, and hence operates strictly on MSVC's intermediate representation which lacks information about tokens or the AST, it's unlikely due to tokens.

std::exception does not take a string in its constructor, so most likely you used std::runtime_error. std::runtime_error has a pretty complex constructor if you pass into it a long string. If it's a small string then there's no issue because it stores its contents in an internal buffer, but if it's a longer string then it has to use a reference counting scheme to allow for its copy constructor to be noexcept.

That is why you can see different behavior if you use a long string versus a short string. You can also see vastly different codegen with plain std::string as well depending on whether you pass it a short string literal or a long string literal.

Post reply on HN