Diagnosing GIMP Slowness on Large Images: A Tile‑Memory & Swap Checklist

Recognizable Condition

When working on a high‑resolution canvas (e.g., 100 MP+), GIMP suddenly slows to a crawl after applying a filter or making several edits. The UI freezes, the progress bar lags, and the system shows high disk I/O.

Root Causes (Quick Reference)

Cause	Typical Symptoms
Large Undo History on a small RAM machine	Frequent disk spikes, sluggish undo/redo, occasional crashes.
Scratch disk on a slow or full drive	High I/O wait, slow filter application, .gimp‑swap growing rapidly.
Tile cache exceeding L3 cache limits	CPU stalls during heavy filters, memory usage far above canvas size.
Inappropriate tile size	Excessive overhead or wasted memory for sparse images.

Diagnostic Checklist

1. Verify RAM and Swap Usage
   • Run top -o %MEM (Linux) or Activity Monitor (macOS) while editing.
   • Check if GIMP’s process uses >80% of available RAM.
   • Look for a spike in swap file usage (e.g., /var/lib/gc/gimp-swap).
2. Inspect Undo Levels
   • Navigate to Edit > Preferences > Undo.
   • Note the current Undo levels setting.
   • If it exceeds 20 on a 4 GB machine, consider lowering it.
3. Check Scratch Disk Location
   • Open Edit > Preferences > Folders.
   • Locate the Scratch Disk path.
   • Confirm it points to a fast SSD and that the partition has >10 % free space.
4. Measure Disk I/O During a Heavy Filter
   • On Linux: iopstat -t 5 gimp to sample I/O every 5 s.
   • On macOS: sudo iostat -d 5 5 and filter for gimp.
   • High await or svctm values (>20 ms) indicate disk bottlenecks.
5. Assess Tile Cache Size
   • Open Edit > Preferences > Image Display (or Image > Tile Cache in older versions).
   • Note the Tile cache size (usually in MB).
   • Compare to your CPU’s L3 cache (e.g., 8 MB). If tile cache > L3, consider reducing it.
6. Examine Tile Size Setting
   • Navigate to Edit > Preferences > Image Display.
   • Find Tile size (default 256 × 256).
   • For very large canvases, try 512 × 512 to reduce overhead; for small images, try 128 × 128 to save memory.

Fixes Tied to Findings

1. Reduce Undo Levels

Lower the maximum undo history to 10–15. This cuts memory churn and reduces reliance on the swap file.

# Example: set via gimp-2.10 command line (if available)
# gimp-2.10 --no-data --no-splash --batch "(gimp-undo-set-history-size 15)"

2. Move Scratch Disk to an SSD

Change the scratch disk path to a dedicated SSD partition.

# On Linux, edit ~/.config/GIMP/2.10/gimprc
# Set: scratch-disk /mnt/ssd/gimp-scratch

3. Adjust Tile Cache Size

Set the tile cache to a value that fits comfortably within your CPU’s L3 cache (e.g., 4 MB for a 4 MB L3).

# In GIMP: Edit > Preferences > Image Display > Tile Cache Size: 4

4. Tune Tile Size for Image Density

For a 100 MP image, a 512 × 512 tile size reduces tile count and memory fragmentation.

# In GIMP: Edit > Preferences > Image Display > Tile Size: 512

5. Verify Disk Health and Speed

Run hdparm -Tt /dev/sdX (Linux) or diskutil verifyVolume /dev/diskX (macOS) to ensure the SSD is healthy and fast.

Escalation Criteria

1. If performance remains sluggish after applying all fixes, consider upgrading RAM to at least 16 GB for very large projects.
2. For legacy filters that are not multi‑threaded, a faster CPU may be required; benchmark by comparing filter times on different CPUs.
3. Persistent crashes or data loss after reducing undo levels indicate a deeper file‑system issue; check for disk corruption or insufficient permissions on the scratch directory.

Practical Verification

After each change, re‑apply a heavy filter (e.g., Gaussian Blur with radius 50) and monitor:

• CPU usage (should drop if tile cache is tuned).
• Disk I/O (should stay below 10 ms wait).
• Memory consumption (should stay  + 10 %).

Use watch -n1 iotop -k or top -p $(pgrep gimp) to observe real‑time metrics.