Hi David, I have been using htop to monitor what is going on before and after closing. In the past I've used valgrind for C++ projects (openlighting) but this is python/QML with no compiled code (from my side) at all to the best of my understanding valgrind can't help me with this, but I may be wrong.
Memory usage of the newer version of gPodder is definitely higher (it loads a large amount of images) but it's also not released with closing gPodder (which does not background) so I suspect there is some bad synergy happening by a memory leak in system libraries being exasperated by gPodder. I downgraded on my phone and I could push memory usage up by just switching between lots of different pages and it seems pages don't get cleared from memory when not in use, though memory usage did drop a bit when I locked the screen. (By opening all podcast information pages which include logos and all episode listings one after the other I managed to enlarge the total memory footprint [VIRT] from ~500M to 1200M after screen lock it dropped back down to ~850M, resident memory usage [RES] was doubled by this and never dropped back down) In the newer version the episode listings are much heavier because each episode comes with a picture. Thanks, Eli Op ma 13 apr. 2020 om 17:03 schreef David Llewellyn-Jones < da...@flypig.co.uk>: > On 13/04/2020 15:54, E.S. Rosenberg wrote: > > Recently I've noticed my phone running out of memory more often. > > I've update to 3.3.0.14 but I also released a newer version of gPodder > > which may be guilty of this. > > However closing gPodder does not release memory so I'm not really sure > > if I should blame myself or that lipstick is after all leaking memory. > > Also how does one optimize a qml/python apps memory usage? Neither is > > managed to the best of my knowledge. > > I may have time later to test the level of involvement of gPodder by > > downgrading. > > Hi Eli, > > If the memory isn't released when gPodder's closed (assuming the app is > definitely closed, and not just hidden), then it's highly unlikely to be > gPodder draining your memory. > > A very simple way to check memory usage is just to take a look at the > output of "top". The following will show everything running ordered by > memory usage and keep it updated: > > top -o %MEM > > Or if you just want to track gPodder you could use something like this: > > top -o %MEM -p `pgrep sailfish-qml` > > I used sailfish-qml as the app name, since probably that's what gPodder > will be called if it's QML/python-only, but you can change it to > whatever you're interested in. > > Finally I was going to suggest to run it with valgrind, which gives a > summary of memory leaks when you close the app and I've found useful in > the past for C++ code. Unfortunately when I tried it on another QML-only > app the results weren't very helpful at all. So this may not be a > helpful route to go down. > > Nevertheless I uploaded an RPM to openrepos in case it's helpful in some > other context: > > https://openrepos.net/content/flypig/valgrind > > David > -- > Website: https://www.flypig.co.uk > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org