[maemo-developers] sp-endurance and device memory usage (was: Why should I write apps for Maemo?)

[From: Eero Tamminen]

Hi,

(CCing to maemo-devel as this might contain useful info also
for others.)

ext Dawid Lorenz (maemobile) wrote:
> There's one thing missing from these graphs - Modest.
> I am pretty sure it could have major impact on memory
> usage/performance. Or maybe I'm wrong?

sp-endurance in the public repositories lists only processes that
are both present in multiple endurance snapshots and which memory
usage changes.

In your data, the Modest PID changed in every snapshot.


>> To see a summary of the leaks, look at the summary sections at
>> the end of the HTML files.  The leakers differ after you had
>> rebooted the device (e.g. systemui doesn't leak nearly as much).
> 
> Hmm... could systemui be related with the way I lock my device,
> ie. using power key button doble-click? I sometimes do that, but not always.

Apparently it leaked (very, very little) whenever it was topped or
lock/unlock was used, both of these issue are fixed in PR1.2.

Before that's released, systemui should be safely killable
(& auto-restarted) as long as you don't do it too often in a row.


>> You could try whether killing the leakers you see in the endurance
>> report help with the device usability.  Except for things like X
>> and D-BUS, killing them should usually just re-start them (when
>> needed), not cause device reboots. :-)
> 
> I just killed addressbook-factory and that instantly released
> 8% of swap space! Killing off browser & browserd release another 2%.
> I try killing off pulseaudio and mafw wrapper once I get home and
> stop listening to the music as I type this email on the train ;)

(Note to others: addressbook-factory, browser ui and mafw-wrapper
memory leakages are fixed in soon-to-come PR1.2.  Pulseaudio memory
usage is dependent on what it's clients do.)


> Btw, what exactly is browserd for and is there a way of completly turning it off

There's a master browser daemon for quickly forking pre-initialized
browser engine instances.  Then there are separate pre-started browser
engines for Browser and Messaging apps.  Without pre-starting, the
startup would take close to 10s.


> (if for example I decided to switch to Fennec completely)?

PR1.2 fixes last known wakeup-on-background issue in microb engine
(related to animated images, reported also to upstream mozilla).
When I last tested Fennec few months ago on my N900, it was constantly
waking up on the background, so I would suggest at least closing it
when you don't use it.

Note that worse than something using a lot of memory, is it being
active and using it also on the background like Fennec does
(I've also noticed Maep to do that, I've filed Garage bugs about
that)...

It's useful to check occasionally with "top" whether some application
you left on background is active or not.  If it is, without a good
reason, please file a bug.

Of the pre-installed apps, browser stops activity 1/2 min after going
to background (this www-page JS timers disabling timeout is configurable
from Browser options), and media player of course continues playing
music on bg, but everything else should stop working once it's finished
what user asked it to do.


>> Could be.  Maybe you could run "mem-cpu-monitor" from the sp-memusage
>> package in XTerm and ask it to track pulseaudio to catch what causes
>> it to grow?
> 
> Wow, that mem-cpu-monitor is very nice tool. Like it. I need to
> get my head around all these tools at some point, however I might
> just stick to endless (?) wait for PR1.2 first, just to see whether
> leaking issues have been indeed ironed out in that release. :)


	- Eero