>It's set to either 15 megs or 10 megs.  However the disc is not being

Too low, enough to edit a logo, but not for big images. 3500 * 2800 * 3
bytes = 29.4E6 bytes, as you see it is a lot more than 15MB (near two
times), so Gimp moves data to disk as soon as you load the image.

I have used Gimp with images as big as yours, multiple layers and it was
fast, reason? I set the cache size to 128MB or more (the machine had 256),
and I hope to fine tune it as soon as I have time to test it more (but I
guess that 128 - 192 will be good, after all, my old machines had 64MB in
the best case, and I had done medium works with them).

>thrashed, throughout the redraw all the CPU time is being eaten by gimp,
>i.e. it's processor-bound, not I/O bound, if it was a cache issue then I'd
>expect large amounts of disc I/O but I'm not seeing that.

How did you meassure the CPU and IO loads? I think your meassurements are
not correct. Unix system internals are really strange, I always remember the
famous discussion in GNOME list about Shared memory, Resident, etc. It seems
most people meassure wrong.

BTW, Unix "trashing" is rare to find, or at least to heard. When it moves
data to disk it does not sound like Windows Machine Gun Swap Routine (TM),
just clickclick. Watch the LED, it should be always ON (or look like it is
ON, you know that eyes are not perfect), but the disk may not make loud or
rare sounds. At least under normal conditions (a 1GB DB in a 64MB computer
is not normal). ;]

Conclusion: raise the limit and complain again if Gimp is not fast.

GSR
 

Reply via email to