mintMenu memory leak?

[Kaivalagi]

I am noticing Python memory usage of over 50Mb only after maybe 1-2 hours of up time.Could this be just down to mintMenu or more than that? I do have Deluge running (Python based?), but this is listed separately in the process list.

It's not that this sort of memory usage is out of the ordinary for Windows, I just thought I should add my 2 pence...

I am running Daryna 4.0 (Gnome) which on the whole is the best Linux distro I have come across, thanks clem!

Mark (Kaivalagi)

[clem]

To tell you the truth I'm starting to think it's simply the python interpreter not freeing memory... I can see mintupdate taking a lot, and if I start a lot of programs the memory used by mintupdate actually starts to decrease... I looked a lot at the code and I don't see anything wrong with it.. plus there are a lot of people screaming for better python memory management if you look in Google.

That added to the fact that I'm seriously annoyed with python not using line delimiters... I might switch to another language in the future, perl, java, or whatever lets me develop solid apps with GTK.

Clem

[clem]

The more I think of it the more I'm thinking of perl actually..

[kaivalagi]

If the problems truly sit with Python itself then I would suggest sticking with what you have written and waiting for a newer version. Could it be that the libraries you are using are to blame instead?

I am sure that if there are that many developers out there having memory issues with it, it wont be long before some progress is made in tightening the memory leaks.

It would be a shame to switch to Perl! I am a visual studio developer by trade and am finding python very usable in comparison to .net (in the short time I have looked at it). I have just started to play around with Python, messing around with dialogs to handle shell commands for common tasks.

What sort of memory management does Python use, is it much like Java and .net? Can you use finally and using blocks in code to handle the disposing of objects? Apologies for my ignorance, it's just that so many memory issues I have encountered in .net are cured through the cleaning down of objects explicitly, rather than expecting the runtime to do it for you (as should be the case).

[Kaivalagi]

Further to the above, I had a chat with some fellow developers today and we concluded that it's probably best to have python (and perl scripts) running one off tasks and not cycling round again and again, this can cause memory usage increase, as memory is not released necessarily. I think this is what the mintUpdate.py script does? I haven't had time to learn Python properly yet or trace through the code

If I've not got the wrong end of the stick, one option would be to develop the system icon and have it call the main python function as a separate process, that way all memory used by the main update process should be released when it's complete. Not sure how you could go about handling this, maybe have a simple file lock to tell the system icon a process is already taking place so it doesn't spawn it again...

Other than that I think it would be best to wait for a newer python release and see if there are improvements in memory use.

Regards,
Mark

[subslug]

If I leave LockerSync, which is also a python app running it's memory usage will increase gradually as well as Mint Menu so if I had to guess the issue had more to do with Python as a whole rather than just Mint Menu.

Currently I'm not sure if this Python thing is as big of an issue as the memory leak that seems to be going on with Firefox. My Firefox session is currently using 130.6 Mb of memory and it's steadily climbing. That's with only three tabs opened and none of them rendering flash. I often find Firefox completely freezes unless I close it when I leave my pc for any time.
I'm going to turn off all ad ons and see if that changes anything.

[phantommaggot]

i switched to the debian menu and it still bogs down eventually, just depends on how long my system is up without a restart... given it dosent slow down as fast as it did with mintMenu it still does it eventually..

i have 1gb ram
and i usually only leave firefox open with around 3-4 tabs on a regular basis.

[clem]

Hi,

It's my number one problem to solve for Mint 5, so don't worry it's being closely looked at right now

Anyway, just to let you know:

mintMenu 2.x was fast and didn't slow down (not that I was aware of anyway). The problem with mintMenu 2.x was when installing or removing apps... it was taking a while for it to refresh... sometimes making it unresponsive for a minute or so.

Lars looked into that and refactored a lot of code. With mintMenu 3.x (currently in Romeo) this problem is gone. I don't want to go into too much details as I'm not entirely sure of the big picture yet.. but basically mintMenu 2.x loaded everything in cache and only when a new app was installed did it refresh itself... resulting in a fast menu app, but with long and unresponsive delays after APT was used.

With mintMenu 3.x the refresh is constant (not literally of course), so it doesn't matter whether you use APT or not... or whether you install/remove something, mintMenu 3.x refreshes every time you select a category (and I think also when you don't actually...). It doesn't seem to refresh everything, but only what you're looking at. This results in a faster refresh (so no unresponsive lag time after using APT) but also, and for some reason, it makes mintMenu heavier on the resources and as you can observe... it makes it become slower and slower...

Lars: Please correct me if I said anything wrong. I'm still looking into this and I'm not 100% sure as whether my description is fully correct or not.

But anyway, mintMenu 3.x is truly brilliant... and at the same time it's not usable yet due to this performance issue. So I'll definitely tackle that before it makes its way into Mint 5.

Lars: By the way, if you run a second instance of mintMenu... all of sudden both menus start to be fast again... as if the second menu woke something up or forced everything to be loaded in memory again... it's really strange.

Clem.

[clem]

By the way, the latest versions of mintUpdate are not using much RAM anymore. The refresh process was basically moved to another script in order to force python into releasing the memory. I'll check mintMenu 2.x to see if it's memory footprint is similar to versions 3.x and if that can explain the performance issue.. but my intuition is that there's something funny in the way it listens or checks for updates from the applications pool. It's a bit too soon for me to be sure as I still can't put my finger on the cause of the problem.

Clem

[clem]

Follow up on this: I installed an old version of mintMenu (the one that came with Bianca) and the performance issue is still here. The funny thing is, if I launch mintMenu on its own (from a terminal, not as an applet) it's fast... both for the old mintMenu and the new one.. so it looks like it's a problem related to the way Gnome handles applets... very strange.

Clem

[clem]

Hi Lars,

I did a lot of testing last night and the funny thing is.. when I run mintMenu directly it's lightning fast. It's only when it's run by the gnome panel as a bonobo server that we're seeing performance problems...

I guess moving to C wouldn't harm anyway.. but still, I wonder why the panel or Bonobo is making mintMenu so slow. I removed all session tools (networkmanager, mintupdate.. etc) to make sure the panel was running only a few things.. same story.

Be careful if you're making changes, I'm working on 3.2 right now so you're on an obsolete version already

Clem.