Bug 289680 - ICCProfile wastes a lot of memory (high memory footprint on startup)
Summary: ICCProfile wastes a lot of memory (high memory footprint on startup)
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: ColorManagement-Backend (show other bugs)
Version: 2.5.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-23 16:44 UTC by Andi Clemens
Modified: 2022-02-01 11:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.1.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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