RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

question about speeding up gegl

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.
question about speeding up gegl Nicolas Robidoux 30 Jan 01:15
  question about speeding up gegl Sven Neumann 30 Jan 22:09
Nicolas Robidoux
2009-01-30 01:15:00 UTC (almost 16 years ago)

question about speeding up gegl

Hello:

Is there a way of compiling GEGL so that resamplers (scale and rotate) run faster when used as BATCH filters (from xml scripts)?

We are writing an article in which, among other things, we benchmark by rotating large images and up- and downsampling them. So, we'd like to know if GEGL svn trunk can be compiled so that it runs faster, mostly so that we don't paint an unnecessarily slow picture of GEGL on the basis ofconfigure options which apply to another situation.

We understand that GEGL is meant to be used in an interactive environment, which means that caching results is generally a good thing. However, in the context of batch processing, it does not.

Hence the above question.

-----

Another question (less pressing):

Is it possible to configure GEGL so it works as fast as it can as a BATCH filter on images which are larger than RAM?

Nicolas Robidoux Universite Laurentienne

Sven Neumann
2009-01-30 22:09:53 UTC (almost 16 years ago)

question about speeding up gegl

Hi,

On Thu, 2009-01-29 at 19:15 -0500, Nicolas Robidoux wrote:

Is there a way of compiling GEGL so that resamplers (scale and rotate) run faster when used as BATCH filters (from xml scripts)?

We are writing an article in which, among other things, we benchmark by rotating large images and up- and downsampling them. So, we'd like to know if GEGL svn trunk can be compiled so that it runs faster, mostly so that we don't paint an unnecessarily slow picture of GEGL on the basis ofconfigure options which apply to another situation.

It would help if you could profile your use of GEGL. Given the knowledge of where the processor spends most of its time, it should be easier to find out if there are options you could tweak to improve this. Or do you have the impression that the speed is I/O bound? In other words, does GEGL use all of the CPU cycles available or is it trashing your disk?

You might find sysprof useful as a tool for profiling GEGL: http://www.daimi.au.dk/~sandmann/sysprof/ It doesn't require you to recompile the code you want to profile and there's chance that your distro has sysprof packaged already.

Sven