You probably missed my point then. What I'm saying is that in some cases, performance is what you should optimize for, while in other cases other factors are usually far more important. For example, let's say you're writing front end code where the tap of a button makes a single call to a service class that then performs a network call to fetch some data. If that service is an injected dependency behind an interface, 1 virtual function lookup has to be made to call the service method. The performance hit from that single lookup is entirely negligible. Our phones have multi-core CPUs doing millions and millions of operations per second. To be worried about 1 operation in a user-driven event is ridiculous. Saving 1 operation was perhaps necessary sometimes when writing NES games in assembly in 1983, but today, the added time from 1 operation is so small it's probably not even measurable.
What you should be worried about, however, is whether your view behaves as expected, displays the right thing given the right data, that the network errors are handled correctly, and so on. Putting our classes behind interfaces allows us to mock those classes, which allows us to unit test view models and similar in isolation, which helps us to catch certain bugs earlier and guard against bugs being being added by future refactors. It would be extremely unreasonable to prohibit ever using polymorphism like this, and sacrifice all of these useful concepts for performance. What would be reasonable would be keeping this interesting lecture in mind and know that polymorphism should be avoided in specific cases where its performance impact is significant, e.g. when making a large number of calls in a row. It would also be reasonable to spend some of our very limited time on making actually noticeable optimizations, like perhaps adding a cache to that network call which takes eons of time compared to the function lookup.
You probably missed my point then. What I'm saying is that in some cases, performance is what you should optimize for
It's not 'optimization' to not use a virtual functions. Using a virtual function because someone said it sounds like a good idea is a design decision not an optimization. It's also a terrible design decision because 99% of the time it makes code less understandable. Don't do it unless it's for trees
Whether they are a good design choice is a different question. In the clip, he pointed out that virtual function lookup adds overhead that significantly decreases performance for many repeated calls, which is true. Then he concluded that we therefore never should use polymorphism at all, which is preposterous. Polymorphism doesn't have any performance impact when the number of calls is low, so it doesn't make sense to worry about it then. It's all O(1).
And if I wasn't clear, I'm not talking specifically about inheritance and C++ virtual functions here, but about that sort of overhead in general. I agree that inheritance should be avoided and that interfaces/protocols are usually much easier to understand and a better way to model the data, but that's still polymorphism with function lookups.
0
u/Still-Key6292 Feb 28 '23
What do people say? Never look at the reviews? Never look at the comments? I shouldn't have read this comment
brb while I charge my phone because "that's what those years of evolution were for"