26 July 2008

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.

4 comments:

powered_by_tux said...

Just wanted to let you know that 1.4.18 is way faster for me than the previous version. No more annoying delays or lags, yay. Let's see if it will stay this way after having used it for a while.

Thank you very much.

Lars said...

Thanks for this feedback!

Anonymous said...

the version 1.14.18 is faster as previous versions. but the poll make 1/5 feeds and slepp for 10 - 30 sec.

and the favicons of sites don't downloaded or view this in the list


Thanks for all you work, liferea is cool :)

Lars said...

@anonymous: Feeds and favicons not updating are often an effect of a stuck download queue. Liferea currently has a fixed concurrency of 5 parallel downloads and if there are 5 "hanging" downloads it will seem like everything is hanging... Also the favicons are downloaded after all feeds are processed, so hanging feed updates will cause hanging favicon updates.