On 11/23/2010 09:03 AM, Torsten Neuer wrote: > ... elision by patrick ... > And this is the real trade-off: trading maintainability of code - just > imagine someone wanted to increase the precision of the "radius" > parameter - for a minimum amount of speed. That's true. > This function IS CALLED ONLY ONCE for the whole filtering progress! > > Which means that this is clearly the least important place for code > optimization in this plug-in, since the speed gained from making the > matrix pre-computed will dissolve into nothingness with growing images! > > How many microseconds does the computation of the matrix take ? > Did anyone evaluate this yet ? It's minimal, you wouldn't have to evaluate it to tell that. Inspection of the algorithm is enough. Sorry, didn't mean to cause an uproar! I was just being playful with code when someone was asking about the convolution matrix, and my brain took off down a tangent. No one in the conversations suggested that there was a problem, or that we make any changes to the code. We were just discussing one of the details about the algorithm and alternate ways of doing it. It's fun to talk about algorithms and the tradeoffs between calculation vs tables. No one said that there was a problem that had to be fixed. The tradeoffs are minimal, although your point about the maintainability of the code changing if someone wanted to change (not just increase, any change) the precision of the radius is the only point I've seen that could really differentiate between the choices. That's always an important consideration in design of stuff like this, "Would the precision of the input parameters ever change?" Thanks for bringing that into the discussion and thanks for joining the discussion. > I mean, before starting to speculate about methods of optimization for a > certain part of code, one should first have a look at what can be gained > there - in this case: near zero. No one _was_ talking about optimizing. It was just a sort of fun water cooler discussion about code. It's true, that in this case there's not much to differentiate between the choices, but it's important to think about choices like this because we're not always maintaining code, sometimes we're writing new code. One of my favorite things about this plugin is the clarity of the code and the documentation. There's even one routine written twice, once in a clear way, disabled, and then again in an optimized way with a comment that it's the same algorithm as the clear one with loop invariants hoisted out of the loop. What a great way for a developer to communicate. Much better than the usual code with no comments. Patrick _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
