Re:“Clean” Code, Horrible Performance
by cratermoon on Tuesday February 28, 2023 @09:31PM
(#34978036)
Right? His Area() function does the calculation from the scratch every call. Either a) make the Shape immutable and calculate area once, at create time, or have the mutator functions recompute the area when they are called. At that point Area() just returns an f32, and the compiler can do all kinds of optimizations.
Re:“Clean” Code, Horrible Performance
by cratermoon on Tuesday February 28, 2023 @11:34PM
(#34978804)
Speaking of mutators, his example depends the code executing in a single thread. What happens if calls to mutate the shape and calls to calculate the area are interleaved?
Re:“Clean” Code, Horrible Performance
by incrudible on Wednesday March 01, 2023 @04:25AM
(#34980361)
You are completely changing the problem. Remember, this is an example, the code does the same thing in either implementation.
Re:“Clean” Code, Horrible Performance
by cratermoon on Wednesday March 01, 2023 @09:49PM
(#34991311)
> completely changing the problem
Indeed. That's the point. Why let someone with an axe to grind define the problem in a way they can solve with their axe? The author is using optimization as the frame for rejecting a particular way of working, I'm pointing out that the definition is set up to make the solution work. I don't concede the terms of the debate before it even begins.
If shape Area is computed often enough that you care about inlining the calculation, why not compute & store it every time the height / width change. That’d be easy enough in an architecture based on information hiding, and might illustrate a legitimate engineering trade-off between those architectural choices.