gwibber uses a lot of memory

I see the same, only worse.

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 8060 robin 20 0 867m 318m 14m S 0 15.9 26:10.39 gwibber
 8794 robin 20 0 874m 296m 19m S 14 14.8 222:17.24 firefox

Not too bad here.

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8299 aqeel 20 0 122m 58m 20m S 0 5.9 2:13.35 gwibber

Purely twitter account seems to average around 40-60 MiB. Facebook is the likely source of high memory usage, based on what I've heard.

$ top | grep gwib
 2517 bugabund 41m 12m 517m 20 0 S 40.3 1.1 1:19.61 /usr/bin/python /usr/local/bin/gwibber

Accounts: twitter, jaiku, identica, pidgin, pingfm
12MiBs aint that bad.

My large memory usage is coming from just identica and facebook.

My memory usage (mentioned above) is from twitter, facebook, identi.ca & jaiku. ~50MB is not that much for all these.

I've replaced minidom with feedparser in the facebook module and several other places. This seems to have significantly reduced the rate at which memory consumption increases.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32551 myrtti 20 0 513m 83m 25m S 8 2.2 0:15.43 gwibber

Jaiku, identi.ca, twitter, ping.fm, flickr, digg, facebook...

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.

Gwibber trunk is still memory consuming application:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11279 dmig 20 0 322m 27m 10m S 0.0 1.1 0:09.85 /usr/bin/python /usr/bin/gwibber-service
13882 dmig 20 0 581m 143m 28m S 0.0 5.8 0:08.69 /usr/bin/python /usr/bin/gwibber

Only 2 accounts: twitter and facebook.

Gwibber uses an enormous amount of RAM when it's checking my Twitter account and maxes out my dual-core CPU as well.

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19012 tom 20 0 152m 16m 2500 S 17 0.9 0:01.86 gwibber-service
19007 tom 20 0 128m 16m 2572 S 15 0.9 0:02.55 gwibber-service
19003 tom 20 0 104m 16m 2572 S 13 0.9 0:02.74 gwibber-service
18997 tom 20 0 104m 16m 2576 S 12 0.9 0:04.57 gwibber-service
19013 tom 20 0 152m 16m 2612 S 11 0.9 0:01.27 gwibber-service
19002 tom 20 0 104m 17m 2760 S 11 0.9 0:02.05 gwibber-service
19017 tom 20 0 176m 16m 2500 S 11 0.9 0:01.06 gwibber-service
19018 tom 20 0 176m 16m 2484 S 10 0.9 0:01.05 gwibber-service

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.

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19040 tom 20 0 202m 88m 25m R 64 4.7 0:16.24 gwibber
 2073 tom 20 0 74220 16m 3144 S 47 0.9 23:37.28 beam.smp
19157 tom 20 0 200m 16m 2572 S 17 0.9 0:03.12 gwibber-service
19158 tom 20 0 200m 16m 2612 S 14 0.9 0:02.15 gwibber-service

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 2073 tom 20 0 76116 15m 3144 S 49 0.8 23:48.82 beam.smp
19242 tom 20 0 200m 16m 2520 S 27 0.9 0:02.09 gwibber-service
19228 tom 20 0 176m 16m 2520 R 15 0.9 0:02.22 gwibber-service
19219 tom 20 0 152m 16m 2572 R 14 0.9 0:02.88 gwibber-service
19210 tom 20 0 104m 16m 2576 S 13 0.9 0:03.45 gwibber-service
19243 tom 20 0 200m 16m 2520 S 13 0.9 0:01.04 gwibber-service
19215 tom 20 0 128m 16m 2572 R 10 0.9 0:03.15 gwibber-service
19220 tom 20 0 152m 16m 2612 S 9 0.9 0:02.10 gwibber-service
19209 tom 20 0 104m 16m 2612 S 9 0.9 0:02.63 gwibber-service
19229 tom 20 0 176m 16m 2612 R 8 0.9 0:01.69 gwibber-service
19040 tom 20 0 202m 88m 25m R 6 4.7 0:22.51 gwibber
19214 tom 20 0 128m 16m 2612 R 5 0.9 0:02.41 gwibber-service

So I have it as gwibber, gwibber-service and an apparently-related process called "beam.smp" ... which also has a bug report in Launchpad for using lots of processor cycles on CouchDB contacts lookup: https://bugs.launchpad.net/ubuntu/+source/erlang/+bug/458453

There is definitely a memory issue in gwibber,
using Gwibber 2.30.0.1 in lucid, uses 1.2gb to use 1 facebook and 1 twitter account!

 PID PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 1166 20 0 1349m 1.2g 17m S 0 30.6 57:07.06 gwibber

> The relevant bug to follow there is this one: https://bugs.webkit.org/show_bug.cgi?id=24001

That bug was marked RESOLVED FIXED on 2009-12-20 - would be great to hear that Gwibber's memory usage might soon be coming down as a result!

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.

I just killed a gwibber process using 190 MB RES / 693 MB VIRT (it was no. 1 on the system, ahead of Chrome with half a dozen tabs open). A brand new process uses 81 MB RES / 582 MB VIRT. I've got one Twitter account and one Facebook account.

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?

Chris
Are you able to replicate this on the version from the gwibber daily builds PPA? There may be more interest in the bug if it is proved to be still leaking memory in the latest version.

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.

Using 2.31.92 version from gwibber daily PPA:
Memory usage:

VIRT RES SHR S %CPU %MEM TIME+ COMMAND
193m 80m 25m S 0 2.0 0:21.16 gwibber 45mins
237m 125m 25m S 0 3.1 2:32.06 gwibber 3 hrs
471m 359m 25m S 0 8.9 17:49.03 gwibber 22 hrs
510m 398m 25m S 0 9.9 21:00.74 gwibber 26hrs

1 twitter and 1 facebook account - relatively low traffic

After 1 day, gwibber has become the highest memory user on the machine (more than 30 tabs on firefox open for similar period).

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 have noticed large memory usages for some time now,

my gwibber is 2.32.2-0ubuntu2, and last night i was unable to hibernate because gwibber was using ~1.2gb

yes, it had been running for a long time, i dont notice the usage with 4gb ram, but my swap is only about half that size.

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 get about 120 Megs in Precise Gwibber, so issue is still there, probably you add all widget at one time and do not add them on demand

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.