Worldclock plasmoid: How to reduce memory footprint of not-shown layers, especially geodata?
Friedrich W. H. Kossebau
kossebau at kde.org
Fri Aug 12 16:31:17 UTC 2016
Hi,
currently the Marble Worldclock plasmoid uses up to 100 MB*. Even if only
shown in sizes of 400*100. Which is not really acceptable and needs fixing.
* E.g. when run isolated with the plasmawindowed tool.
MEH, WHAT IS GRABBING ALL THAT MEMORY?
Trying to understand where the memory goes, I applied "valgrind --tool=massif"
to "plasmawindowed org.kde.plasma.worldclock" and also to the hello-marble
example with "earth/bluemarble/bluemarble.dgml" as theme, to have a pure
QWidget-based comparison.
And I found that seemingly more than the half of the memory is used by
GeoData* instances, both with hello-marble (which peaked 72 MB at heap use)
and with the world-clock plasmoid (who seems to spent the 28 MB additional
memory used in the dri driver).
AHA, THE DGML INCLUDES QUITE SOME GEODATA, AND WE ONLY NOT DISPLAY IT
Looking at bluemarble.dgml, I learn that indeed quite some geodata is part of
that theme, in the "naturalearth" layer and the "standardplaces" layer.
And while for the plasmoid we untoggle the display of almost all that data, it
is still part of the geodata model in the working memory. After all the
methods are called "setShowFoo(bool", not "unloadFoos(bool)" :)
So needed would be a way to also remove that unused data from the working
memory or prevent it even being loaded.
HM, WHAT TO DO?
My initial reaction would be that the Plasma applet and also the Plasma
wallpaper need some custom DGML, tailored to only contain data needed for
their use-cases, instead of trying to reuse one of the predfined DGMLs.
Would that be the best solution?
What other approaches would there be rule at run-time over what is predefined
in the DGMLs?
Cheers
Friedrich
More information about the Marble-devel
mailing list