Re: [Gegl-developer] VIPS and GEGL performance and memory usage comparison

[Øyvind Kolås <pippin gimp org>]

On Fri, Jan 29, 2016 at 5:41 AM, Sven Claussner <scl gplus gmail com> wrote:
> On  28.1.2016 at 10:29 PM Daniel Rogers wrote:
> > I am confused.  What technical reason exists to assume gegl cannot be as
> > fast as vips? Is it memory usage? Extra necessary calculations? Some way
> > in which parallelism is not as possible?
>
> you might have misunderstood me. The performance comparison only shows
> that VIPS outperforms GEGL at least in this test.
> Technical reasons can be found here:
> http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use
>
> In a mail John explained the differences to me:
> "Gegl is really targeting interactive applications, not batch
> processing, and it's doing a lot of work that no one else is doing,
> like conversion to scRGB, transparency, caching, and so on."

GEGL is doing single precision 32bit floating point processing for all
operations, thus should not introduce the type of quantization
problems 8bpc/16bpc pipelines introduce for multiple filters - at the
expense of much higher memory bandwidth - the GEGL tile cache size
(and swap backend) should be tuned if doing benchmarks. If this
benchmark is similar to one done years ago, VIPS was being tested with
a hard-coded 8bpc 3x3 sharpening filter while GEGL was rigged up to
use a composite meta operation pipeline based unsharp mask using
gaussian blur and compositing filters in floating point. These factors
are probably more a cause of slow-down than the startup time loading
all the plug-in shared objects, which still takes more than a second
on my machine per started GEGL process.

/pippin