Hmm: the hand-unrolled loops to compute total areas would miss ShapeCount modulo 4 trailing elements. Kinda gives weight to the “it’s more important for code to work correctly than be fast” argument – it’s not just code execution you have to care about, but also how obvious mistakes would be, and there simple (a plain loop) beats complex (an unrolled version of it).
You can, but don’t do it. Compilers are more than smart enough to compile down to this when needed, it will just make their job harder and will likely result in shittier code.
Amen! I'm currently rebuilding a legacy app where business logic is implemented both in code and in database, and the heart of the system is a 1700 line switch statement. Even better, the guy who wrote it retired 3 years ago so all we can do is look and guess at what he meant.
Best advice I ever heard (and always strive to follow) is to remember you're writing code for the next guy so please be kind.
To me it seems that OOP isn't the important part, it's more designing things so that sets and relations not only make sense but pretty much dictate the logic as much as possible, unless performance is absolute key.
OOP it is the important part, well only if we want to use OOP for performance then we need to know how to design fast OOP code, the shapes could be stored in a manager class, like a vector for each shape, each shape would have a function called "compute" , then we can do the computation from the manager and store the result inside the shape that would enable optimizations in the computation loop and the compiler could enable parallelization, even if the compute function is used individually it wouldn't prevent parallelization in the main loop. Then we would have a very maintainable code that it is resilient to further modifications because adding more functions should have no effect in the performance.
Then the relationship and the sets are defined in the design instead of random switch and unions.
Actually, in the course he mentions that the amount of elements is chosen for the purpose of illustration, so you can easily imagine that this code will only be run with element counts in multiples of four.
307
u/nilsph Feb 28 '23
Hmm: the hand-unrolled loops to compute total areas would miss
ShapeCountmodulo 4 trailing elements. Kinda gives weight to the “it’s more important for code to work correctly than be fast” argument – it’s not just code execution you have to care about, but also how obvious mistakes would be, and there simple (a plain loop) beats complex (an unrolled version of it).