Speed of darktable 5.6

Software darktable
1

I already mentioned here, that dt 5.6 feels a bit sluggish on my system. It doesn’t make any difference if I use the appimage or install the deb file.

Now I have downloaded the latest nightly build 20260712, and I’m really surprised, that it makes a huge difference on my sytem. The nightly is fast and a pleasure to use. On the stable release I have to wait after every change I make on a module to see the result. On the nightly build the chnages are visible nearly instant.

Anybody has a clue what can be the reason?

2

Any differences in configuration?

3

Nope, I even tried using the same config folder. Even then the nightly build is much faster.

4

The reason for such changes is usually a developer, @hannoschwalm being the primary suspect. :slight_smile:

3 Likes
5

If so, wouldn’t it make sense to implement these changes into stable as quick as possible? @Jens-Hanno_Schwalm already pointed me here to the master branch. Which I tried, but the master branch on OBS is versioned with 5.5.0 and brought no improvements.

If these are stupid questions, I’m sorry.

6

There are a few more PRs pending. I’m sure the fixes will be merged as soon as Hanno and the others feel they are ready. It’s pretty complex stuff.

2 Likes
7

Thanx for information. Then I will wait and use the nightly as my main version for the moment.

8

That’s an old master, from before the 5.6 release, which is where the regression was introduced, and so is not going to have the fix.

See here:

1 Like
9

I had the same impression. I wondered whether OpenCL had been properly enabled. It wasn’t enabled, and everything was grayed out.

I noticed that I had two graphics drivers installed. I disabled the Intel graphics driver, restarted Darktable, and it installed some components related to the NVIDIA driver. Since then, it has been working much better.

10

This is a more general question, but related to this topic. Suppose I can invest time in improving darktable performance, what would a good approach to do that?

Of course I would like to improve the performance, but not introduce any bugs or side effects.

11

There will be quite huge improvements for dt pixelpipe code quite early in 5.8 dev, i will ping you if that’s done and maybe we find something that fits you :slight_smile:

7 Likes
12

Sounds great!

13

I updated to 5.6 about the same time as I upgraded my CPU. I noticed 5.6 being slower.

AMD Ryzen 7 3700X → Ryzen 7 5800 XT. GPU (Nvidia GTX 1660 6GB) and OS (Windows 11 25H2) are the same.

Supposedly the CPU change should delivering roughly 33% faster single-thread performance, a 25% boost in multi-threaded tasks. I get that darktable relies on a lot of GPU processing. But editing just feels slower.

I went down the OpenCL and dt-performance analyzer worm hole.

debug mode shows OpenCL is enabled and working. No messages about CPU fallback.

 DEVICE VERSION:           OpenCL 3.0 CUDA API=300
   DEVICE_TYPE:              GPU, dedicated mem
   GLOBAL MEM SIZE:          6144 MB
   MAX IMAGE ALLOC:          1536 MB
[opencl_init] OpenCL successfully initialized. internal numbers and names of available devices:
[opencl_init]		0	'NVIDIA CUDA NVIDIA GeForce GTX 1660'
[opencl_init] FINALLY: opencl PREFERENCE=YES is AVAILABLE and ENABLED
device 'NVIDIA CUDA NVIDIA GeForce GTX 1660' id=0: 89274 out of 89274 events were successful and 0 events lost. max event=1838

I ran the darktable.info benchmark vs. an early windows nightly just after the 5.4.0 release. It showed slightly faster CPU tasks and slightly slower GPU tasks. But nothing earth-shattering. Sub 3 second end-to-end is perfectly usable.

bench compare
bench compare1256×1050 88.4 KB

One difference between the benchmark and actual usage is the GUI. Is there something about the gui in interactive mode that makes it feel slower in 5.6.0?

14

There is an issue in 5.6 that makes dt preview to have more pixels, so it takes longer. It is fixed in master. You can wait until 5.6.1 or compile to the 5.6.1 tag. The nightly now has future work for 5.8, so some small risk.

3 Likes
15

I’m puzzled by this, since having just now run git-fetch, I cannot find any tag containing “5.6.1”.

git-tag | grep 5.6.1 | wc
      0       0       0

And the fix does not appear under the 5.6.x branch:

git-branch -vv --remote --contains 163082c9
  origin/HEAD   -> origin/master
  origin/master dc58cf0ba1 Pixelpipe 5.8 overhaul for efficacy

git-branch -vv --remote
  origin/HEAD            -> origin/master
  origin/darktable-5.6.x 95a8378d68 Update es.po
  origin/master          dc58cf0ba1 Pixelpipe 5.8 overhaul for efficacy

The GH issue and PR are both marked Closed.

So if I want my local build to stay on the 5.6.x branch, it appears I’ll have to git cherry-pick the fix into a local fork of 5.6.x – assuming the change applies cleanly – and proceed to testing it.

16

Okay, the git cherry-pick resolves to a no-op, because the fix is already under branch 5.6.x, as e92edad2fb:

git-show e92edad2fb
e92edad2fb
       Mon Jun 29 17:21:19 2026 +0200   Hanno Schwalm
Fix preview pipe dimensions for performance
...

git-branch -vv --remote --contains e92edad2fb
  origin/darktable-5.6.x 95a8378d68 Update es.po
17

Yes, the 5.6.x branch. The tag gets created when the branch is ready for release.