On Fri, 2006-10-13 at 16:29 +0200, Øyvind Kolås wrote: > On 10/12/06, Daniel Rogers <daniel@xxxxxxxxxxxxxxxxx> wrote: > > On Oct 12, 2006, at 2:03 AM, Øyvind Kolås wrote: > > > On 10/12/06, Daniel Rogers <daniel@xxxxxxxxxxxxxxxxx> wrote: > > >> sllooooooooooow. I've encountered this oh-so-wonderful abstraction > > >> before (JAI uses it, among others). Making a method call in the inner > > >> loop of your pixel calculation routine is a big-nono. The first > > >> optimization you will make is to remove that. Typically, the common > > > Any such optimizations are premature optimizations at the moment. > > > At the > > > current stage making the source code of the included operations > > > general as well > > > as easy to read, understand and debug is more important than > > > efficient code. > > > The operation that geert is currently working on is a displacement > > > map, what > > > you are suggesting would lead to writing a separate displacement > > > map operation > > > for each interpolation method. This would lead to very unwieldy code. > > > Yeah, the IP libraries I've worked with all do something similar, > > unfortunately. > > Something similar to what? Having a proxy object for doing interpolation or > implement separate displacement etc. operation per interpolator? > > If you mean the first, I do not find readable code unfortunate, a > problem with the current GIMP code base IMHO is that some algorithms > are optimized beyond recognition. No, I meant the later. I am all in favor of readable code, actually. I like the particular interface we are discussing. Too slow is still too slow, however. My experience has shown that when performance matters, that abstraction is the first to go. I'm not saying it's a bad idea, I am just bringing up what I've found to be a thorny issue. -- Daniel > > /Øyvind K. > _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
