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