Although memory is an issue - for most people it's not a problem. The resources problem is not a simple matter of Gwibber hanging itself up - often it won't grey itself out and sit quietly. Once or twice I have forced it to quit because it can render the whole desktop unresponsive - and I do like to build up my 'uptime' and hate to have to reset (it's now not so easy for most people to quit X server and log in again...

I generally just use Gnome-Do to post to identi.ca now - when my internet connectivity is poor, I can guarantee Gwibber can't post - even if the experimental modes are disabled.

WebKit is largely responsible for Gwibber's excessive memory consumption right now. The problem is that the default caching behavior used in the GTK+ WebKit port is intended for web browsers and not applications like Gwibber. This is a problem that needs to be addressed upstream. The relevant bug to follow there is this one: https://bugs.webkit.org/show_bug.cgi?id=24001 I'm going to experiment with some of the patches attached to that bug. If those fixes significantly improve Gwibber's memory footprint, I'm going to talk to some people and see if we can get them applied sooner rather than later.

I'm tackling other resource consumption problems, too. The JavaScript method used to push messages into the content area in trunk is really ridiculously processor intensive. The new template-theme-engine branch almost entirely eliminates that problem.

It takes up so many processor cycles that it pushes the temperature sensors on my AMD Turion64x2 from about its normal operating range of 120° to well over 140°. I've taken Facebook off Gwibber and that helps a little, but not much. Here it is with Facebook added back in.

It grows about 100MB per day with 1 Twitter and 1 FB account. It's not memory over-usage, it's a memory leak, as the application memory usage seems to grow indefinitely. Mine has gotten as high as 650MB after 6 days. I'm guessing that Simon had his running for even longer to get to 1.2 GB. A default desktop app on an LTS release probably shouldn't leak memory this badly.

Here's an illustration of the memory behavior of Gwibber on my system. The graph plots resident memory numbers reported by ps against total process time. It represents about two days of running Gwibber on my laptop under normal use and ends with Gwibber using 238,616 KB. Gwibber is the number one process on my system for memory usage (6.5%).

It looks to me like the rate of increase is nearly constant. That might indicate it's not due to an accumulation of messages, which ought to vary over time. Maybe there's some connection resource that's not being released after every refresh?

Simon, Neither the PPA version nor the version in the Maverick repo work for me (they both start and no messages appear), so I can't verify this behavior with the latest code. Anybody running gwibber can easily attempt to confirm my data by periodically running "ps -C gwibber -o time,rss,cmd" and posting the results. If this has been fixed in the trunk, it is well worth backporting to Lucid, as this behavior has a significant effect on the performance of the system as a whole.

testing gwibber on natty with facebook+twitter seems to have improved things. duplicated bugs and comments on this bug tend to refer to huge memory leaks, which i can no longer reproduce in gwibber .
memory leak issues may have coincided with the facebook update issues e.g. bug #595265 ?
can other affected users confirm that the bug is now resolved?

I noticed that a large capacity of CPU usage with the memory use.
It takes up to 99% of my CPU capacity.
My system is Ubuntu 10.04.
The gwibber I am using is 2.30.30-0ubuntu.
I can terminate gwibber using system monitor but I have to kill all the gwibber services.

I've never noticed high memory use with Gwibber. My problem has been with the high CPU usage. I have a dual core Atom N270 processor, and Gwibber has one of the cores running constantly high ranging between 94% and 107% (I didn't even know the graph could go over 100%). And this is when the program is technically closed. I can't watch videos any more because of the high CPU usage, and Thunderbird freezes periodically, making reading mail a pain. In the end, I had to completely eliminate Gwibber just to get some decent functionality back. I'm using Seesmic Desktop (an Adobe AIR program) to check my feeds now, but I like the convenience of Gwibber being connected into Ubuntu. I hope they can get this sorted out.

A major goal of the 3.1.x series of gwibber was to reduce the memory and CPU usage. I am marking this as incomplete, and declined for the 2.x series. Gwibber >= 3.1.5 is significantly better in this regard.

I doubt we'll get it down much more, it is easily 1/5 or less than what it used to be. The only way we can cut it back more is to not create multiple streams, which would mean we would have to destroy and recreate the stream view as you switch between the views. Right now it creates all of them and you just slide between them.