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.

Gimp-developer mailing list

Reply via email to