KFileItem (Re: Jenkins build became unstable: kdelibs_frameworks_qt5 #982)

[David Faure]

On Tuesday 06 August 2013 20:53:05 Frank Reininghaus wrote:
> OK, I see now that it uses pointers to be able to modify the actual
> KFileItems in KDirListerCache (if it would just keep KFileItems and
> modify these, I guess that they would just detach from the ones inside
> the cache, leaving those unchanged).

Yes.


I suppose a solution would be to use a QLinkedList in KDirListerCache. This 
would basically cancel the Q_MOVABLE_TYPE for that particular list (since it 
would need to allocate nodes), but every other KFileItemList out there would 
still benefit.

> It looks like a solution for this problem is more complicated than I
> thought, so maybe I'll just revert the commit to make Jenkins happy
> again. However, I still think that making KFileItem a Q_MOVABLE_TYPE
> might be a desirable long-term goal because it saves quite a bit of
> memory (32 bytes per KFileItem on my system).

32 *bytes* ? Are you sure? I think you meant 32 bits?

In fact I'm surprised. sizeof(KFileItem) = sizeof(void*), right? So QList 
should already lay out the kfileitems next to each other in memory, the only 
issue is that insertion makes copies, but I don't see where a memory saving 
happens. I thought QList only wasted memory for types bigger than a pointer 
(in which case it had to allocate nodes) ?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5