On Fri, Jan 29, 2016 at 5:41 AM, Sven Claussner <scl.gplus@xxxxxxxxx> 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 _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
