When you try to edit many files in a sequence ( example pages of a comic) krita goes on adding memory to the ram usage . Ideally krita should re-use the allocated memory of the previously closed image for the newly opened one but krita goes on adding extra memory. So much so that my 16 gb memory gets full and systems starts to use swap which also eventually runs out. I have discussed this on IRC and scottpy also noticed the unusual memory usage on windows. I have also shared the test files with dmitry and scottyp Reproducible: Always Steps to Reproduce: 1.open one file. do something in it like changing color space resizing layers etc 2.close the file and open another one. 3.repeat the process Actual Results: you'll notice that krita adds to the memory usage Expected Results: Once image is closed krita should use the memory for the other image opened after that
this may be related to this bug report -> https://bugs.kde.org/show_bug.cgi?id=363334
I can confirm this with my test I did last week. I am on a Windows 10 box. Raghukamath gave me a series of large KRA files (over 1GB). Memory doesn't seem to be getting recycled. Every time a different file is opened, Krita allocates more memory instead of reusing any of the existing memory.
Created attachment 99858 [details] memcheck log
Created attachment 99859 [details] massif run Opened and closed a bunch of images in a row.
Git commit 550ff114cbae42c33edb667981d091e2ac4346f5 by Dmitry Kazakov. Committed on 15/07/2016 at 10:01. Pushed by dkazakov into branch 'kazakov/memory-optimizations'. Release all the tile pools forcefully when a document is closed This approach is a bit hackish, but it is the best thing we can do. When the document is closed and the pool still contains a few tiles, we artificially "swap-out" the tiles into a QList, purge the data in the tile data pools and "swap-in" the tiles back. Surely, we will not get an ACM award for this solution, but at least it works ;) M +72 -9 libs/image/tiles3/kis_tile_data.cc http://commits.kde.org/krita/550ff114cbae42c33edb667981d091e2ac4346f5
Git commit a8f901e40fb7de35a29a4b4803ccbacab802c8bd by Dmitry Kazakov. Committed on 15/07/2016 at 10:01. Pushed by dkazakov into branch 'kazakov/memory-optimizations'. Fix releasing the node pixes memory when closing the document KisNodeFilterProxyModel should not store any pointers after the image has been closed. M +1 -1 libs/image/kis_default_bounds.cpp M +9 -0 libs/ui/kis_node_filter_proxy_model.cpp M +2 -0 libs/ui/kis_node_filter_proxy_model.h M +1 -1 plugins/dockers/defaultdockers/kis_layer_box.cpp http://commits.kde.org/krita/a8f901e40fb7de35a29a4b4803ccbacab802c8bd
Git commit 54282a72cee6256f29be9970793b32f6ffae6aa1 by Dmitry Kazakov. Committed on 15/07/2016 at 10:01. Pushed by dkazakov into branch 'kazakov/memory-optimizations'. Implement data pool for the chunks in openGL canvas updates This patch implements KisTextureTileInfoPool. A special object that keeps track of all the chunks allocated during the openGL canvas updates. This class is also capable of tracking multiple openGL tile sizes and color space pixel sizes. It should fix the most of the memory fragmentation problems, especially on Windows. Related: bug 363334 M +0 -1 libs/ui/CMakeLists.txt M +8 -1 libs/ui/opengl/kis_opengl_image_textures.cpp M +4 -0 libs/ui/opengl/kis_opengl_image_textures.h A +156 -0 libs/ui/opengl/kis_texture_tile_info_pool.h [License: GPL (v2+)] D +0 -22 libs/ui/opengl/kis_texture_tile_update_info.cpp M +58 -72 libs/ui/opengl/kis_texture_tile_update_info.h http://commits.kde.org/krita/54282a72cee6256f29be9970793b32f6ffae6aa1
Thanks dmitry for fixing this
Git commit 5884065cb3fe96d294387e3e436c7b6be4da03a8 by Dmitry Kazakov. Committed on 20/07/2016 at 14:00. Pushed by dkazakov into branch 'kazakov/memory-optimizations'. Don't keep the default tile data blocked from swapping Summary: We don't access the raw data of it usually. And is cases we do we should block it separately. This patch is needed to be able to migrate the leftover of tiles to the new pool when a document is closed. Release all the tile pools forcefully when a document is closed This approach is a bit hackish, but it is the best thing we can do. When the document is closed and the pool still contains a few tiles, we artificially "swap-out" the tiles into a QList, purge the data in the tile data pools and "swap-in" the tiles back. Surely, we will not get an ACM award for this solution, but at least it works ;) Related: bug 363334 Implement data pool for the chunks in openGL canvas updates This patch implements KisTextureTileInfoPool. A special object that keeps track of all the chunks allocated during the openGL canvas updates. This class is also capable of tracking multiple openGL tile sizes and color space pixel sizes. It should fix the most of the memory fragmentation problems, especially on Windows. Fix warning Merge remote-tracking branch 'origin/master' into kazakov/memory-optimizations Test Plan: Open any **huge image** in Krita and try to work with it, Krita should not consume more memory with time. The RAM shouldn't also grow with reopening the same large image multiple times. Well, it will grow anyway, but not much. Reviewers: rempt Subscribers: dkazakov Differential Revision: https://phabricator.kde.org/D2236 http://commits.kde.org/krita/5884065cb3fe96d294387e3e436c7b6be4da03a8