Your feedback definitively helped to get a better image of the type of setups out there. Here are my conclusion based on the feedback:
- 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.
- 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.
- Definitively all users suffer from the linear cost of the complex operations (loading huge item lists, full text search).
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.