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.
> 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