Just loading up deskbar, it takes 13 mb of writable rss. This is really bad for an applet. Agreed that something needs to be done here.

We are more than willing to work on this, but I must admit I'm not exactly an expert in memory optimising PyGTK applications. Actually I know nothing :-S

How do you guys suggest we go about this?

rewrite it in C or C++ where you can control this and you don't have MB of interpreter to load at the same time.

I discussed this with Raphael a while ago and we decided that this what not feasible. Ofcourse if 10 seasonened gtk hackers show up on #deskbar one day and decide to spend the next half or whole year on this, I suspect they will be welcome :-)

Well, if anyone has knowledge on how to opitimize Python+GTK memory usage I'm all ears.

Cheers

Another thing is that Deskbar (currently) has an in-memory index of things like the web browser bookmarks, which obviously will be memory-expensive if you have a lot of them.  This also sucks because every time that the bookmarks file changes, we have to re-parse.  It could easily be something like this, rather than the fact that it is written in Python, that is responsible for deskbar's memory usage.

There was an idea kicking around of an SQLite (??) based storage backend for Epiphany's bookmarks and history, which might improve Deskbar's memory usage (if Epiphany is your preferred browser) whilst still allowing you to find-as-you-type your bookmarks.  If you're on Firefox, which is less GNOME-integrated, then you might be out of luck.  :-(

At some point in the future Tracker might also become a a viable metadata storage for deskbar. This will increase start up time and memory usage considerably.

This will be 2.18 at the very earliest though.

Firefox 2.0 will also use a DB to store bookmarks, so we might just be in luck on this point.

Note: in the last post sed -e "s/increase/decrease/g".

Still about Tracker; it looks like Jamie of Tracker fame has abstracted the storage part of Tracker away so that it can use most old self respecting databases around. This might make it more viable for G18, and thus even more exiting for deskbar.

There seems to be a python memory profiler that was written for the google SoC of 2005. I haven't tried it myself, but maybe it can help to catch some low hanging fruit.

Link: http://pysizer.8325.org/

Also, it seems that in version 2.5 python will be able to return some memory to the OS which will probably alleviate this problem.

This bug has no reason to be in the NEEDINFO state. So far the developers are not waiting for info from the user. The problem has been acknowledged.

I am working on the deskbar.index target as described on http://live.gnome.org/DeskbarApplet/Ideas.

Using a DB, Tracker or Beagle as indexing backends might save us some memory (and startup speed too).

I will be actively working on this bug for 2.18 (also through other means than using an on disk cache for the index). Don't expect miracles though - we stick with Python (for now atleast), and memory overhead is inevitable.

Have you guys thought of lazy loading the applet on gnome session startup too? I don't know if that's a direct correlation with memory usage, but deskbar applet is by far the #1 startup hog. Even on an idle gnome session, starting deskbar applet takes a good 5 seconds. What's up with that, it loads all the bookmarks + home folders + history in memory at once?

Here's a few possibly-related links scraped from a discussion on desktop devel: http://mail.gnome.org/archives/desktop-devel-list/2007-December/msg00041.html

Python memory freeing: bug #1123430
 - Will converting all tuples to list make any difference? I think they are slower, but there may be a speed/memory tradeof to evaluate here.

Lazy PyGTK initialization: bug #346946
 - Not likely in the near term I think...

deskbar-applet development has been stalled [1]. Maintainers don't have future development plan so i am closing the bugs as WONTFIX.

[1] http://mail.gnome.org/archives/desktop-devel-list/2011-June/msg00073.html