I draw for 5-8 hours at a time, generally. I notice significant performance decreases over time, peaking at around the 2 hour mark and then remaining. Upon opening Krita and a medium size document, memory usage is around 2.3gb. After several hours of drawing, this peaks at around 11GB. I've never seen it go much over that, regardless of document size. I have allocated 80GB of memory to Krita, and I swap undo after 25GB. Swap file size limit is 64GB If I restart Krita and re-open the document, the performance decrease remains, so I'm not sure if it's an undo history problem. This doesn't seem to be true with a full restart, or if Krita is off for a long enough time(?). [ All comparisons are done on the same document, with the same number of layers, after drawing for 4 hours vs restarting computer and opening the document fresh. ] 'Performance decreases' include: - Lower brush rendering speed (40fps vs 65 usual) - Significant delay (110ms vs <16ms) after brush strokes end before the cursor becomes responsive again - Much slower hiding/unhiding of layers. (1-2 seconds vs 30-50ms) - Layer transformation previewing and processing. Beginning a transformation can take multiple seconds for a preview to load. Applying a transformation can take several seconds vs less than a second. - Undo/Redo gets a significant delay (unmeasured, but I can feel it) I haven't noticed much else, but considering most of these make up 95% of my time in front of Krita, it does become very noticeable. Any advice for how to track the cause down on my end during my usual drawing sessions, without negatively impacting my ability to work would be appreciated. ----------------- System specs: Windows 11 dev snapshot 22622 AMD 5800X hyperthreading disabled 128GB 3600mhz RAM C: WD Black Gen4 NVME Nvidia RTX 3090 21GB Krita system info dump: Krita Version: 5.2.0-prealpha (git d700876) Qt Version (compiled): 5.12.12 Version (loaded): 5.12.12 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.22622 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc. (NVIDIA)" Renderer: "ANGLE (NVIDIA, NVIDIA GeForce RTX 3090 Direct3D11 vs_5_0 ps_5_0, D3D11-30.0.15.1277)" Version: "OpenGL ES 3.0.0 (ANGLE 2.1.0 git hash: f2280c0c5f93+krita_qt5.12.12)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0 git hash: f2280c0c5f93+krita_qt5.12.12)" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions false is OpenGL ES: true supportsBufferMapping: true supportsBufferInvalidation: false forceDisableTextureBuffers: true
Neglected to mention that this is not Windows 11 or 5.2 specific, I believe this has been a problem for me for a couple years now.
Hi, Ralek! Could you please clarify this sentence? > If I restart Krita and re-open the document, the performance decrease remains, so I'm not sure if it's an undo history problem. This doesn't seem to be true with a full restart, or if Krita is off for a long enough time(?). 1) Does the performance degradation persist if you close the document and reopen it **without** restarting Krita? 2) Does the performance degradation persist if you close **all the documents** and then reopen the document in question **without** restarting Krita? 3) Does the performance degradation persist if you close the document, **restart** Krita and then reopen the document?
(In reply to Dmitry Kazakov from comment #2) > 1) Does the performance degradation persist if you close the document and > reopen it **without** restarting Krita? > 2) Does the performance degradation persist if you close **all the > documents** and then reopen the document in question **without** restarting > Krita? > 3) Does the performance degradation persist if you close the document, > **restart** Krita and then reopen the document? Heyo! Had a medium length session today and got to try these out. The ram peaked at 6gb, but a previous session I noticed it was 33GB, so the '11gb limit' in the initial post wasn't true. To answer your questions: 1. Yes 2. Yes 3. No? I swear it did before, but with all documents closed I restarted Krita and it went back down to ~300mb of memory. Usually if I restart it seems to keep it. In fact the 'Krita.exe' process in task manager even says Krita remains 'open' even when I close the window.
Hi, Ralek! What is the size of the image you work with? I mean, size in pixels and average numbel of layers?
Git commit c878c55e1c8eb626b57e0dc51432f4f4427571fa by Dmitry Kazakov. Committed on 01/08/2022 at 14:21. Pushed by dkazakov into branch 'master'. Fix a tiny memory leak in KisTileDataStore The garbage collection has never been started in KisTileDataStore, where we use a hash table as a replacement for the tiles linked list. Though, afaict, this leak could never cause leaks more than 200-300MiB in size. M +2 -0 libs/image/tiles3/kis_tile_data_store.cc https://invent.kde.org/graphics/krita/commit/c878c55e1c8eb626b57e0dc51432f4f4427571fa
Git commit 64026b836b0e456824d3a1bd644501192ad0537d by Dmitry Kazakov. Committed on 01/08/2022 at 14:21. Pushed by dkazakov into branch 'master'. Fix a memory leak in the storyboard caused by a strong pointer to a node M +1 -0 plugins/dockers/storyboarddocker/StoryboardDockerDock.cpp M +1 -1 plugins/dockers/storyboarddocker/StoryboardModel.h https://invent.kde.org/graphics/krita/commit/64026b836b0e456824d3a1bd644501192ad0537d
Git commit cf53533b1d848ababcdffdf3a5cfbb3c0dc4e881 by Dmitry Kazakov. Committed on 01/08/2022 at 14:23. Pushed by dkazakov into branch 'krita/5.1'. Fix a memory leak in the storyboard caused by a strong pointer to a node M +1 -0 plugins/dockers/storyboarddocker/StoryboardDockerDock.cpp M +1 -1 plugins/dockers/storyboarddocker/StoryboardModel.h https://invent.kde.org/graphics/krita/commit/cf53533b1d848ababcdffdf3a5cfbb3c0dc4e881
Git commit dafa966d5ac5a36eb3608d62d8f13ef4c667ca67 by Dmitry Kazakov. Committed on 01/08/2022 at 14:23. Pushed by dkazakov into branch 'krita/5.1'. Fix a tiny memory leak in KisTileDataStore The garbage collection has never been started in KisTileDataStore, where we use a hash table as a replacement for the tiles linked list. Though, afaict, this leak could never cause leaks more than 200-300MiB in size. M +2 -0 libs/image/tiles3/kis_tile_data_store.cc https://invent.kde.org/graphics/krita/commit/dafa966d5ac5a36eb3608d62d8f13ef4c667ca67
Hi, Ralek! Could you please test tomorrow's nigtlies (either stable or master), whether the problem still persists? I have fixed an obvious leak, but there is still an issue of the memory pools, which are not released until you close all the documents...
I'll mark the bug as needs-info for now
(In reply to Dmitry Kazakov from comment #4) > What is the size of the image you work with? I mean, size in pixels and > average numbel of layers? Theyre at 16bpc, and can be anywhere from 2kx2k to 5kx5k, and have between 10 to 90 layers. I'll give the new nightlies a try and see if I notice any difference. I'm not too familiar with memory leaks, if it doesn't get to the point where I'm running out of memory, shouldn't it theoretically not slow down? By the time Krita gets sluggish I still have a good 90gb or so left of ram. And I doubt it's getting up to that much usage from a leak, I can just as easily open/close a bunch of documents and get Krita's ram usage up to 30gb and still not notice any performance decrease.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
> I'm not too familiar with memory leaks, if it doesn't get to the point where I'm running out of memory, shouldn't it theoretically not slow down? The conventional "leak" is when an application loses control of some portion of memory and neither returns it to the OS nor uses it. The leak I fixed could theoretically cause a slight delay, but given its size was rather low, I doubt it could cause any significant slowdown. > And I doubt it's getting up to that much usage from a leak, I can just as easily open/close a bunch of documents and get Krita's ram usage up to 30gb and still not notice any performance decrease. Do I understand that correctly, if you just load a lot of documents that occupy 30GiB of RAM, Krita is not sluggish, but if you work for a long period of time with these documents, Krita becomes sluggish? If yes, should these doucments (you work with for the long time) be huge in size? Or any documents will work?
Hi, Ralek! Could you also answer two questions: 1) What value do you have set in "Undo Limit" option? 2) What maximum size you have assigned to the swap file (on the Performance tab)?
And one more question :) Could you explain in more detail, what do you mean by "sluggish"? Some specific tools work slower? Or zooming/panning? Or menus? Perhaps you could make a video of this state?
And one more test, sorry :) 1) Go to Krita settings, Performance and set "swap undo after" to some really small value, like 50MiB 2) Restart Krita 3) Open your standard huge document Does it look as slow and sluggish as if you worked in it for 6 hours? If yes, then I may have a solution for you :)
Created attachment 151083 [details] Slow stroke completion > Do I understand that correctly, if you just load a lot of documents that > occupy 30GiB of RAM, Krita is not sluggish, but if you work for a long > period of time with these documents, Krita becomes sluggish? Yes. I can make Krita use a lot of ram quickly, but even if it's using 40+gb of ram, it doesn't inherently mean it's sluggish. I've felt it get sluggish when it's been as low as 10gb of ram, and I can also make it smooth while also using 40gb. > If yes, should these doucments (you work with for the long time) be huge in > size? Or any documents will work? The sluggishness only seems to happen with larger documents. This could be correlation though, as larger documents are the only ones I work on for more than 4 hours at a time, while smaller ones usually get finished before then. > 1) What value do you have set in "Undo Limit" option? I have it set to 700 > 2) What maximum size you have assigned to the swap file (on the Performance tab)? I think when I noticed these first issues cropping up, it was set at 50% or 40GB. I've since changed it to 10GB, but it's hard to tell if it's made a difference as I've had a string of smaller projects recently. >Could you explain in more detail, what do you mean by "sluggish"? Some specific tools work slower? Or zooming/panning? Or menus? The entire program acts as though I have a worse processor installed. Basically everything that takes time takes more time. Brush stroke rendering, undoing, redoing, filters, hiding/unhiding layers, transforming layers, magic wand, fill tool, etc. I don't notice a difference in menus but the difference may be too small to be noticeable. Panning and zooming doesn't seem to be affected *as* much, but it does seem ever so slightly choppier. > Perhaps you could make a video of this state? Next time I notice it happening I definitely will take more videos, it's just a bit difficult for the large stuff such as transformations as much of what I draw is inappropriate. Right now I only have video of the brush 'stopping' after every stroke, which is usually a sign that Krita is in this 'state'. Compare the two attachments I have added and notice after each stroke, the brush circle stays behind, as if Krita is processing something now that the line is completed. >1) Go to Krita settings, Performance and set "swap undo after" to some really small value, like 50MiB >2) Restart Krita >3) Open your standard huge document Unfortunately not. Manipulating a large document is still snappy when I first open it. My swap file is on a 7gbps read/write drive so I kind of figured that shouldn't be bottlenecking it. I'm going to be working on some larger documents soon, so I'm going to set my `swap undo after` back to 40GB, and up my undo up to 1000 and see if I can get it acting up so i can do some tests. Thanks for the help!
Created attachment 151084 [details] Standard stroke completion
Hi, Ralek! Thanks for your detailed reply! The videos give a very little, but still some clues :) I will think about that in the background, perhaps I'll get some ideas. The video shows that the problem is not in the swapper thread as I though, but with something in the GUI thread. Because the thing that gets delayed is the brush outline, not the actual stroke. If it was the swapper, then only the stroke would be delayed, not the outline. If you happen to have more videos, please attach them, they might show me lots of stuff :)