Version: 1.3 (using KDE 4.3.2) OS: Linux Installed from: Ubuntu Packages when viewing a folder with many large images in dolphin using thumbnail mode it uses so much ram that the system becomes completely unresponsive as everything else is moved to swap. (this happened on a machine with 4GB of physical ram) the way i see it this boils down to 2 problems: 1) it uses more ram than a single image takes up in decompressed form. i guess this is because it's using multitasking to speed up the calculations on multicore cpu's which is good, but apparently it doesn't take ram requirements into account when deciding how many images to process at a time. the images were 8kx8k with 32 bits per color so each should take up only 256mb. i know these are large images but not *that* uncommon. 2) dolphin makes the decision whether to calculate a thumbnail based on the image's filesize when it should also consider the dimensions. in some cases huge images are very compressible and end up having very small filesizes. 3) the algorithms used seem not to optimized for memory usage. when using weighed average scaling for example there is no need to store the full sized image in memory. just an array of the size of the thumbnail image (with a few more bits per channel) should be enough. this is probably hard to do though as it requires working with the low level functions of several image libraries. ways to reproduce: fill a folder with lots (10 did it for me) of high resolution images and simply open it in dolphin and enable thumbnail mode. 16kx16k png images filled with a single color should definitely work as they will have a small file size but huge dimensions.
Thanks for the report. Which format do you 8Kx8K images have? PNG, JPEG? For JPEG the generating of the thumbnail is done already in a clever way, but I doubt this is the case for other image formats. All thumbnail decoders are outside the scope of Dolphin, so I don't know the code in detail, but if I remember correctly in other formats the image is decoded in full size first and shrinked afterwards. Regarding 1) No multitasking is done here, the generation is queued. Hmm, strange...
i used png. with jpeg images there is no problem. hmm, no multitasking. that's realy strange re4garding the results.
I don't have a lot of 8Kx8K photos (to be precise, zero) so I cannot triage this issue properly. Can someone confirm that this problem still exists with Dolphin 17.12.3? If yes, I'll set this bug to CONFIRMED, if not I'll close it.
No response -> closing. Please reopen if you can still reproduce this behavior with the newest version of Dolphin.
Dolphin 18.04 is still leaking memory during jpg thumbs generation. I have just tested on Arch Linux. open ksysguard to observe ram usage and enable "always on top" for its window open a folder containing thousands of jpg files (my test folder has 2140 files) click "preview" button in toolbar to enable thumbnails while thumbs are generated, scrolls the folder content slowly and observe dolphin ram usage increasing in ksysguard
Well, it's normal that Dolphin is needing more RAM for temporarily storing the thumbnails. Does the usage decrease again if you switch to another folder, containing less images?
Created attachment 112258 [details] ram usage after dolphin 18.04 to generate thumbs of 9512 jpg files (In reply to Julian Schraner from comment #6) > Does the usage decrease again if you switch to another > folder, containing less images? No. Ram usage remains the same until Dolphin is restared. I just repeated the same test using a folder containing 9512 jpg files. My screenshot shows the result.
Created attachment 112267 [details] ram usage after test with a folder containing 49896 jpg files
Needs a heaptrack or valgrind log to verify that there is actually a memory leak. I guess glibc simply doesn't resize the heap on every free() for performance reasons. Additionally, if something was allocated after the thumbnail allocations, freeing them cannot resize the heap. I think there are variables to tune glibc's allocator, but since parsing them is expensive, these are not environment variables. A workaround would be to use mmap() for memory chunks, but the number of maps the kernel allows per process is limited.
==2304== Memcheck, a memory error detector ==2304== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2304== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2304== Command: dolphin /home/stalker/teste ==2304== --2304-- WARNING: unhandled amd64-linux syscall: 332 --2304-- You may be able to write your own handler. --2304-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --2304-- Nevertheless we consider this a bug. Please report --2304-- it at http://valgrind.org/support/bug_reports.html. qt.accessibility.core: Cannot create accessible child interface for object: PlacesView(0x2771e760) index: 9 org.kde.dolphin: Saving view-properties to "/home/stalker/teste" ==2304== ==2304== HEAP SUMMARY: ==2304== in use at exit: 555,777 bytes in 7,695 blocks ==2304== total heap usage: 10,732,810 allocs, 10,725,115 frees, 5,844,996,428 bytes allocated ==2304== ==2304== LEAK SUMMARY: ==2304== definitely lost: 2,086 bytes in 30 blocks ==2304== indirectly lost: 120,799 bytes in 1,314 blocks ==2304== possibly lost: 0 bytes in 0 blocks ==2304== still reachable: 432,892 bytes in 6,351 blocks ==2304== of which reachable via heuristic: ==2304== newarray : 4,264 bytes in 1 blocks ==2304== suppressed: 0 bytes in 0 blocks ==2304== Rerun with --leak-check=full to see details of leaked memory ==2304== ==2304== For counts of detected and suppressed errors, rerun with: -v ==2304== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!