[flagged]
The Performance Impact of C++'s `final` Keyword
191–200 of 385 posts
Re: The Performance Impact of C++'s `final` Keyword
#192[flagged]
Re: The Performance Impact of C++'s `final` Keyword
#193[flagged]
Re: The Performance Impact of C++'s `final` Keyword
#194[flagged]
Re: The Performance Impact of C++'s `final` Keyword
#195[flagged]
Re: The Performance Impact of C++'s `final` Keyword
#196[flagged]
Re: The Performance Impact of C++'s `final` Keyword
#197[flagged]
Re: The Performance Impact of C++'s `final` Keyword
#198tldr: sprinkled a keyword around in the hopes that it "does something" to speed things up, tested it, got noisy results but no miraculous speedup. I started skimming this article after a while, because it seemed to be going into the weeds of performance comparison without ever backing up to look at what the change might be doing. Which meant that I couldn't tell if I was going to be looking at the usual random noise…
>changing the generated code by replacing indirect vtable calls with direct or inlined calls
It can't possibly be doing this, if the raytracing code is like any other raytracer I've ever seen -- since it must be looping through a list of concrete objects that implement some shared interface, calling intersectRay() on each one, and the existence of those derived concrete object types means that that shared interface can't be made final, and that's the only thing that would enable devirtualisation -- it makes no difference whether the concrete derived types themselves are final or not.
Re: The Performance Impact of C++'s `final` Keyword
#199[flagged]
Re: The Performance Impact of C++'s `final` Keyword
#200[dead]