I am aware that Krita’s performance is not the best in this regard.
But today I compared it with Gimp 3.0.2 and noticed extreme differences.
Testfile:
I downloaded the 55 MB Tiff version.
It is public domain.
Notebook PC:
Windows 10
Nvidia Geforce GTX 960M
Intel Core i7-6700HQ
16 GB ram
Nvme SSD
This is intentionally an old slow PC because performance issues are often more obvious on slow systems (on highend machines they might get concealed by the raw compute power).
Examples:
Opening the tif file:
Krita: 30 seconds
Gimp: 4 seconds.
Converting the tif image from grayscale to sRGB:
Krita: 34 seconds
Gimp: 2 seconds
Making a curves adjustment (filter mask):
Krita: around 6 seconds
Gimp: around 2 seconds
Undoing a curves adjustment:
Krita: 5 seconds
Gimp: below 1 second
I could understand if there are some performance differences but those values are so extreme that I assume there is either something wrong with Krita on my specific notebook or Krita in general has performance issues.
Maybe somebody can cross check?
Note: This not about panting performance. I don’t have an issue there.
If it feels borderline like a bug, then I wouldn’t wait and report it in the bug tracker. Otherwise there’s a high chance the problem will make it to the next release.
This issue was driving me crazy.
I could’nt be true that Krita is so much slower than Gimp and all the other software.
After further testing I was able t narrow it down to the kritarc file.
This kritarc file leads to the mentioned slowdown of Krita:
But this kritarc file does not cause a slowdown.
Comparing the files with winmerge shows various differences but I am not able to identifiy which one is the culprit of the slowdown.
The faulty kritarc file has elements of Krita 5.3 prealpha in it.
So I made another test:
Fresh new install of Krita 5.3 (appdata roaming and local completely reset).
Result:
Krita 5.3 with a fresh kritarc file is fast
Krita 5.3 with the faulty kritarc file is slow
Question is, what the heck in the faulty kritarc file is killing Krita’s performance and what did I do to make it like this?
EDIT: Detail info - In the uploaded kritarcs the AVX performance setting is OFF, but this does not make a relevant difference. Even if AVX is ON the faulty kritarc is slow.
EDIT2:
After more testing I found that the following issue (lag in kinetic scrolling) is also caused by the faulty kritarc:
I tested your faulty kritarc and I can confirm a big increase in the opening time of that test tif. In my case it went up to 5 seconds (up from 2 seconds).
After bisecting the file, I narrowed it down to this option in Color Management settings:
This is the key allowLCMSOptimization and if it’s set to false (not checked), then it will make loading the file much slower.
I don’t know much about this feature, but given we’re disabling some optimizations it is probably not a bug. This setting is enabled by default (e.g. when you restore the defaults on that settings page).
opening the tiff file again (without closing Krita inbetween) = 4 seconds
So even if I have a new fresh kritarc and only testing the file loading time there is a severe difference between the Apps.
Summery (worst case):
Krita loading tiff = 24 seconds (lcms optimizations OFF)
Krita loading tiff = 17 seconds (lcms optimizations ON)
Gimp loading tiff = 4 seconds
Paint loading tiff = below 2 seconds
######################
EDIT: The resources are the culprit:
I disabled all bundles in “manage resource libraries”.
Restart Krita
Loding the tiff the first time is now between 5 and 6 seconds
######################
EDIT 2 - Krita 6 vs. Krita 5.3:
I remember there is an optimization regarding metadata in the resourcecache.sqlite in the works. But, I think, it is currently part of the Krita 6.0.0 dev branch.
Test with Krita 6.0.0 prealpha:
All bundles are active:
Loading the tiff after restart of Krita:
Krita 5.3 = 17 seconds
Krita 6.0 = 6 seconds
I’m not sure if that metadata patch is already merged. Last time I checked the MR was still open.
But yeah, that patch is really important, it also fixes other issues such as very slow brush preset changing. A word of warning however, it will make the resources database incompatible with the release version of Krita. So you may wish to back it up before running the new version.
Yes, I have already set each Krita version to use its own resources directory.
Therefore no issues with those ones.
I just which, it would also be possible to setup individual “local” dirs.
Currently only the appdata\roaming\krita directory can be set individually for each version. But the appdata\local can’t.
I am using krita-x64-6.0.0-prealpha-4a0f814a
Whether its the db or something else I am not sure, but 6.0 loads faster
Simply create a user-account for any Krita you want to run, so each version will be physically in its own environment. It works with only one little flaw, the versions in your extra accounts don’t accept drag & drop, you have to open files via your file manager. I tested this method using Windows and Linux, and it simply works, I’m using it for years now.
This even allows you running them simultaneously from your main account, or from any you are just logged in:
Nvme SSD (Toshiba NVMe THNSN5512GPU7 - entry level according to today’s standard)
new PC - notebook about 2021
Windows 11 23H2
Nvidia RTX 2070 Max-Q
Intel(R) Core™ i7-10750H
16 GB ram (DDR4 SDRAM 2933 MHz)
SSD: MVMe ADATA sx8200-512 gts
lcms opt. off = “allow lcms optimizations is off in settings colormanagement”
lcms opt. on = “above setting is on”
restart reload = “Krita was restarted and the tiff file loaded”
reload = “tiff file was closed and loaded again without restarting Krita”
Krita 5.3 Krita 6.0
old PC new PC old PC new PC
lcms opt. off
restart load 24s 8s 12s 6s
reload 10s 6s 10s 5s
lcms opt. on
restart load 17s 4s 6s 2s
reload 4s 3s 4s 1-2s
My conclusion:
Krita 6.0 is faster than 5.3.
Testing performance is more useful for me, if the PC is slow. The differences are more obvious then.
All values are roughly meassured with manually starting / stopping the Windows build-in stopwatch.
@Michelist yes, I am aware of the multiple user accounts (mainly from your posts in the past ), but I think that is like using a sledgehammer to crack a nut. I found a usable way to handle appdata\local for different Krita versions without the overhead of multiple user accounts. I just copy, paste the needed appdata\local krita files from a version specific backup folder and am good to go.
This thread has become a kind of exchange of ideas.
But technically my initial issue was solved by resetting the Krita install / the kritarc file.
So I set the thread to solved.
), but I think that is like using a sledgehammer to crack a nut. I found a usable way to handle appdata\local for different Krita versions without the overhead of multiple user accounts. I just copy, paste the needed appdata\local krita files from a version specific backup folder and am good to go.