Bug 289680

Summary: ICCProfile wastes a lot of memory (high memory footprint on startup)
Product: [Applications] digikam Reporter: Andi Clemens <andi.clemens>
Component: ColorManagement-BackendAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 2.5.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 5.1.0
Sentry Crash Report:

Description Andi Clemens 2011-12-23 16:44:11 UTC 
Version:           2.5.0 (using KDE 4.7.3) 
OS:                Linux

Hi,
 
I wanted to check why digiKam has such a high memory footprint when it just starts (180 MB on my system), and one reason I found are the ICCProfiles.
We read the profiles from the hardddisk (in my case: /usr/share/color/icc), which contains 25 MB of data. We load those bytes into memory, but also
create an cmsHPROFILE in IccProfile::open(), which also contains those 25 MB in the end.
So when loading ICCSettings, digiKam already wastes 50 MB of RAM.
 
Sure we need to load the ICCSettings, but we do not need the data twice.
Wouldn't it be enough to just keep the cmsHPROFILE handle in ICCProfile (d->handle), and delete the data (d->data) after successful loading of the profile?
 
This will prevent us from wasting a lot of RAM.
Unfortunately, a lot of functions need to be changed to work only with the handle (if that is even possible).
 
Andi

Reproducible: Always

Steps to Reproduce:
start digiKam

Actual Results:  
memory is allocated twice

Expected Results:  
should be allocated once
Comment 1 Andi Clemens 2011-12-23 16:46:04 UTC 
In bool CIETongueWidget::setProfileData(const QByteArray& profileData), we take the profile data and (again) create a new cmsPROFILE object. Taking a look at the memory usage with massif and the "taskmanager", it seems like again 25 MBs are allocated. 
Can't we use the already existing handle of the ICCProfile object here and pass it as a reference to this method?
Comment 2 caulier.gilles 2011-12-23 18:07:18 UTC 
Andi,

I think it's fine. But take a care that lcms is not re-entrant in version 1.x. In 2.x it's fixed but a lot of code need to be ported in digiKam.

So, you can try as well and look if in intensive workflow using CM, all work fine.

Marcel has written this CM interface, but he is certainly in vacancy. In all case i meet him in January at Genoa, i will remember to talk about it.

Gilles Caulier

Gilles
Comment 3 Marcel Wiesweg 2011-12-26 21:19:11 UTC 
The cmsHProfile handle is needed to use the profile with lcms - already to retrieve metadata such as description. The data is needed to compare two profiles for identity, and to embed a profile into an image. As far as I know, there is no way to retrieve the original data from the cmsHProfile handle.

Originally, the intention was to open all profiles, read the decription, then close them again to free memory. Apparently, that does not work but I never investigated.
Comment 4 caulier.gilles 2013-11-27 13:22:02 UTC 
Andi,

Since digiKAm support LCMS2, this entry still valid ?

Gilles Caulier
Comment 5 caulier.gilles 2014-08-23 11:48:10 UTC 
Andi,

Do you seen my previous comment ?

Gilles Caulier
Comment 6 caulier.gilles 2015-05-10 16:59:47 UTC 
Marcel, MAik,

I cannot reproduce the problem with LCMS2. At least memory finger print is not too huge due to CM.

Can you reproduce the problem ?

If not so, as LCMS1 is removed in KF5 port, we will able to close this bug with 5.0.0 release.

Gilles
Comment 7 caulier.gilles 2016-07-04 16:43:15 UTC 
Since 5.0.0 we use only LCMS2 and this problem is not visible anymore in valgrind

Gilles Caulier