How to optimise Gimp resource usage

Since I have one computer for the NZ Rail Maps project that is mostly used just for Gimp for mosaic creation and as it has got 32 GB of RAM and 100 GB of Linux swap on a partition of the SSD I need to make sure it uses the available system resources efficiently. One of the nice little things in Gimp 2.10 is the Dashboard dock which can show you how Gimp is using the resources in your system.
The computer has two disks that are relevant: The boot/install SSD,  which also now has separate root and tmp partitions, and a separate partition for Linux swap; and the home volume which is made up of two separate 2 TB disks in a software RAID-1 array (mdadm).
Gimp uses two different areas in particular, called Cache and Swap on the dashboard. Cache is system memory, including Linux swap space. Swap has nothing to do with operating system swap, but is actually the directory shown as Swap folder in the top level of the Folders tree in Gimp’s Preferences dialog box. So it’s important to understand the terminology and what it means. Because you can’t point that Swap folder value at your operating system swap partition or file.
So in the System Resources area in the Preferences dialog the main setting that comes into usefulness there is the Tile cache size and to start with in my system this was set to half of the actual physical RAM or about 16 GB. And what happens is as soon as half the memory is filled then Gimp will start saving stuff into the Swap folder which is its own space wherever you have put it, not the system swap partition.
Now there are a lot of possible ways to optimise the way Gimp uses its resources. For example:
  • You could have a SSD partition that is specifically for Gimp’s use (I did have one before called AppSwap) which is the folder for Swap folder mentioned above. I was able to make this work in earlier versions of Gimp. However in Gimp 2.10 being a Flatpak install, because of the inherent sandboxing in this packaging environment, you can’t use a different disk as a swap location. (It might be possible to use a link to redirect to a different disk but I haven’t tried this). I made this by chopping the swap partition in half to get the AppSwap partition on the SSD where the swap partition is also stored.
  • The other idea that came to mind was to remove the linux swap partition and replace it with a linux swap file that is stored on the SSD in the same partition as what you have set Gimp to use as swap. This is just a tweak of the previous description that makes sure the same partitiion is used flexibly for all swap whether OS or application specific.
SInce we use the flatpak installed version of Gimp I have had to go back to using linux swap as my preference and then making sure Gimp prefers it. The way to do this is quite simply to set that Tile cache size value to, for example, 66 GB – which is half of the total of RAM and swap space on my system – or we could even set that higher if we were confident that was available. I have to do some playing sometime to see how Gimp performs with other applications running, but it is showing this usage as soon as the memory gets full that it is going into the SSD swap and is being reported as such by the OS. Right now I have an image loaded that is using 49 GiB of Cache and the Swap isn’t being used at all. As I have some stuff to try to add into this very big mosaic (12.6 GiB when saved to disk) we can see this is easily the biggest mosaic I have worked on (the previous record was 11.5 GiB) and it will be interesting to see how much bigger it can get before the system is too slow to be usable. 
Funnily I can’t remember what values I had the previous installation of Gimp set to use, and I am only really familiar with Qgis usage of swap. And funnily all this big mosaic stuff is partly due to trying to optimise resources so that Qgis won’t run out of memory – by making smaller tiles, which means in this case a grid of 64 tiles each 4800×7200 pixels. But mostly the extra resource usage is from combining several sets of tiles together in one file and in this case with four separate locations in the tiles I may yet have to split some of them out if the system can’t cope with the resource usage. So this is an interesting trial.