https://bugs.kde.org/show_bug.cgi?id=505199
--- Comment #9 from Roland <carbonwer...@hotmail.com> --- Hello. Sorry, I havent had time to debug. Perhaps tomorrow. As regards the database, Im running SQLite locally. I have several instances of digiKam configured (only 1 runs at a time (I make an effort to manually kill processes that dont terminate with the GUI, as this has been a problem since the new installer (the much larger download) was seen), per your notes on how to configure separate configuration profiles. One instance has a large number of files (approx 200,000) stored locally on an SSD. This is largely smaller jpg/png content (typically <200kb per). There are some number of relatively large photos- AI upsampled files in the 50MB range- probably 100 or fewer. There are some number of video files, but only for the purposes of renaming/organizing when the files are moved out to a separate storage system. In another instance, there are a moderate number of files (20,000) for a total about about 9GB- almost all <200KB jpg/png types. That instance has the content on a SAN (fast Ethernet- nearly as fast as local access), with the database local on an SSD. Another replicates that config, with far fewer images (more like 2,000)- though it has on average much larger files (typically RAW images in the 1-5MB range). The larger of the 3 collections doesnt run face recognition, but does have fingerprints. The medium sized instance has both facial and image fingerprint data. The smallest has only image fingerprints. In all 3 cases- if digiKam is started and then closed, I will see it hold between 602MB and 632MB until its process is killed. So, I dont know what is being cached, but given the huge disparity in file counts and image vs facial fingerprints, I would expect to see a much larger variance if images or thumbnails are being cached etc. Seems more plausible this is something like a thumbnail cache, where those are fixed pixel size. So, if the system holds say the last n thumbnails accessed in cache, that might explain why this value is relatively constant. The properly running application in idle mode (just some thumbnails showing- no secondary windows or tools active) holes about 1.3GB RAM in all 3 instances- so that doesnt seem to be sensitive to the number of files in the collection. Roland -- You are receiving this mail because: You are watching all bug changes.
