Re: [Gimp-developer] Ways to improve Gimp 2.9 performance

[Elle Stone <l elle stone gmail com>]

I followed Nicolas' suggestion and recompiled babl, gegl and gimp with
CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3". The computer
didn't blow up or anything. But I can't say whether Gimp runs any
faster.

The idea of optimization seemed promising and I found this thread:
http://www.gimpusers.com/forums/gimp-user/14320-benchmarking-gimp-gegl#message66197

Does optimization depend on the actual processor? Is there a set of
optimizations that makes sense for a circa 2005 AMD Opteron 252 (soon
to be 262) processor? It has built-in floating point etc, was
considered very fast when doing mathematical operations (that's why I
picked it). What about these: -Ofast -ffast-math -ftree-vectorize ?
Others? Is there any danger to the computer when recompiling packages
using these flags? Or just the danger of the occasional math error?

 What about cairo, gtk, etc? Would it make sense to compile these from
source using optimizations of some sort or another? Or are they
already compiled with all sensible optimizations by openSUSE?

On 2/28/13, Daniel Sabo <danielsabo gmail com> wrote:
> You might want to try running gimp with GEGL's swap turned off, this will
> avoid filling up your drive with cache files:
> GEGL_SWAP=RAM gimp-2.9

Does this mean Gimp and gegl would be competing for my meagre 4gb of
ram? I didn't know gegl wrote cache files. Where does gegl write its
cache files?

> If you don't have OpenCL set up forcing it off will give a bit of a
> performance boost (due to a bug in the detection code):
> GEGL_USE_OPENCL=no GEGL_SWAP=RAM gimp-2.9

How does one set up OpenCL? Is it just a matter of having the right
graphics card and driver? I will try both ways, with and without
opencl, and with nvidia driver and nouveau driver (both have OpenCL
support, it seems) and see if there seems to be a difference. Is there
a way to tell Gimp to use or not use OpenCL? Or a way to tell if it
really is being used?

> Painting speed is due to bugs in GEGL and Gimp's paint core, there's really
> nothing you can do right now to get it speedy.

Ah, well, someday... Other things are also slow. Just hiding/unhiding
a layer is slow, until the image is resized down. 768x512 is
reasonably fast, though the brush is still slower than I'd like it to
be (but useable).

When compiling Gimp, would any of the following compile options speed
things up while using Gimp? --without-libexif --without-aa
--without-libxpm --without-libmng --without-wmf --without-webkit
--without-librsvg --without-poppler --without-print --without-gvfs
--without-alsa --without-mac-twain --disable-gtk-doc
--without-script-fu --disable-python  --without-dbus
--without-linux-input  --without-hal

And while I'm asking questions, what is the "Linux Input Controller
module"? Does it have anything to do with tablet support (I use a
tablet)?

Sorry to be asking so many questions! I've been using Gimp a lot in
the last couple of weeks and liking it more and more and more, except
for the speed of execution. So I'm trying to figure out what the
options are for improving performance.

Elle

-- 
http://ninedegreesbelow.com - articles on open source digital photography