Fix for 100% CPU Usage Problem

After reports from several users that tested with the new release 1.4.18 I believe the 100% CPU issue along with other related symptoms is fixed. Thanks to everyone who retested!

Here is what happened: the release 1.4.16 did bring a DB schema migration that fixed a design problem that caused "loosing" of comment items in the DB. Comments must be removed when there parent items are removed and this didn't work well before 1.4.16. Now I have to admit I tested the comment removal with 1.4.16 very well and it worked as expected, but I failed to notice that the changed DB schema caused the parent item removal to silently do nothing.
The effect is a slow one: your DB file grows and on each feed merge you get more and more old items that should have been removed due to the cache size setting. Now merging (sometimes including full text comparison) against a growing list of items becomes slower each time. For users with lots of feeds updated regularily Liferea finally became unusable because it was merging items constantly.

Now when you start 1.4.18 you still might see some CPU usage during the first update run, because it has to delete a lot of stale items, but afterwards it should run as fast as earlier versions.

Everyone please upgrade to 1.4.18

Performance Poll Results

First thanks to everyone who answered the three questions!

Your feedback definitively helped to get a better image of the type of setups out there. Here are my conclusion based on the feedback:

1. A significant amount of the users is subscribed to a number of feeds that is often twice the expected number of feeds. The Liferea target use case that I had in mind up to now was only up to 100 feeds. I think it is necessary to correct the number of acceptable subscriptions to somewhere around 250 and ensure performance with such a number of feeds.
2. Not all but many users (feels like 80%) do suffer from bad performance. I consider all GUI delays for simple actions (e.g. switching feeds, marking a single feed read) > 2s as bad.
3. Definitively all users suffer from the linear cost of the complex operations (loading huge item lists, full text search).

Now just redefining the target use case won't do anything good. The question is wether the implementation can be improved to significantly improve the performance. And the answer is simple: No. It can't. The current overly simple design is chosen and limited based on the efforts spent on the project. "Simple" means both simple use cases and no elaborate internal architecture.

So the problem is to solve the issues above. To enable better scaling the internal architecture has to be changed. Right now feed merging (downloading the XML, parsing it, merging items against DB) is done synchronously in the GUI thread. This makes it easy to implement, but hurts each time you navigate Liferea while a background update is in progress and results are processed. The second point from above could be addressed by correctly decoupling GUI and merging. The third point could be solved by shifting the focus from processing subscription caches as a whole to batch processing their items in background...

But not to forget these are only ideas. And Liferea is in need of developers! I'm a professional SW tester with some administration skills and do the development only as a hobby. While I'll try to improve the program other really skilled developer might be able to do the same much much better with less effort.

So again: Please consider contributing code!

Concerning immediate solutions: please try the upcoming release 1.4.18 which should solve the 100% CPU issue.

Performance Poll

Today I'd like everyone following this blog (or accidentily reading this) to take part in a small poll. I'm interested in subjective performance feed back.

Please answer the following questions using a comment post:

1. Is Liferea loading feeds / search folders quickly enough?
2. How many feed subscriptions do you have?
3. What is the longest unresponsiveness in seconds when you use Liferea. Please name the feature causing it.

Just post something like

no, 100, 5s clicking on "Unread" search folder...

You can post comments anonymously!

Serious Problems with XulRunner 1.9

With more and more distributions upgrading to the new XulRunner version 1.9 more and more users send bug reports of Liferea becoming unusable because of constant 100% CPU usage.

Right now I'm sorry to say that I have no clue what causes this, debugging is still going one. Hopefully we will find the problem.

Affected versions: There seems to be no limit to the affected versions. I got reports from 1.4.12 up to 1.4.16b all affected. The common symptom was all setups are using a recent XulRunner 1.9. Until now there were no reports about setups with XulRunner 1.8 having the problem.

If someone reading this with insight in XulRunner/Gecko/Mozilla has any idea please post a comment or send a mail!