[Kde-pim] [mobile] Memory usage in KOrganizer-mobile

Eduardo Fleury eduardo.fleury at openbossa.org
Thu Oct 28 14:38:07 BST 2010


Hi there,

We've been tracing the memory usage of korganizer-mobile when in the "new
appointment" screen, in order to search for villains :-).

Our current findings so far are:

--- each QML object uses aprox. ~2kb.
The memory footprint of the Calendar screen was reduced from 800kb to 600kb
by using less QML items and states in its construction.

--- Images are usually large since they are stored in memory in an
uncompressed (pixmap) format, that means a 800x480 pixmap background uses
~1,5 mb.
However, if the same image file is used across different Image { }
components, the memory usage is kept constant. We could try to reuse images
as much as possible

--- The three C++ IncidenceEditors (CollectionCombo, GeneralEditor and
MoreEditor) together add up to 3,6 mb of memory usage
I'm not familiar with the internals of such elements, one initial idea was
to try and avoid keeping all of them in memory at the same time, by using
Loaders, for instance.
One problem I had with that approach is that MoreEditor (at least) is not
happy about being created and destroyed several times. It seems it register
itself with the IncidenceView and BadThings happen if I delete it and create
again. Probably a dangling pointer somewhere is leading to a segfault.

Maybe if we could have the concept of "loaded" / "unloaded" in these guys,
so they could reduce their own memory usage when not needed. Taking into
account we are never using the MoreEditor at the same time as the other
editors, we could have only one in "loaded" state at at time

--- DraggablePanel / Dialog don't have an "expanded" property I could use to
control the loaded/unloaded state of a Loader component
Actually, by looking at the current design of Flap.qml it seems to be though
in a way to allow any arbitrary values (0.0 - 1.0) to be set as its
"extension". Is this a design requirement? I tend to believe we could
simplify its implementation and export such "expanded" property in an easier
way if we could assume flaps are either "collapsed", "animating" or
"extended". Do you guys have any thoughts on that?

cheers,

-- 
Eduardo M. Fleury
OpenBossa - INdT
http://eduardofleury.com/
http://www.openbossa.org/
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list