On Sat, Jan 28, 2012 at 6:21 AM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
* Chris Siebenmann <cks@cs.toronto.edu> [2012-01-28 01:05]:
> I should mention explicitly that I had the same number of feeds and
> entries (or possibly less; I believe I did some trimming when
> I upgraded). On effectively the same collection of data, Liferea 1.8
> performance regressed relative to what I was used to on 1.2, despite
> running on a faster machine. Operations that I was used to performing
> on 1.2 without problems got significantly slower and more 'bursty'.
>
> (I would have kept running Liferea 1.2, but I also jumped from Fedora
> 8 to Fedora 15 and Liferea 1.2 doesn't run or build on Fedora 15 so
> I didn't have much choice. I actually upgraded in two steps; 1.2 to
> 1.6, which then started crashing so I got the latest git source, built
> 'almost 1.8', and moved to that (then updated the git repo and rebuilt
> a few times since then).)

Iíve tried upgrading from 1.2 on my main machine many times over the
years but performance has never been close to acceptable. (On another
machine I keep Liferea current.) That machine has ~600 subscriptions and
an archive of ~427,000 items Ė almost 750MB of XML. The biggest single
feed file has ~30k items. (Items per file forms a classic long tail:
only 5 feeds have > 10k items, ~90% of them have < 1k, and almost half
of them donít even have 100 items.)

On this database 1.2 performs terribly too, with minutes-long freezes
and 100% CPU hogging, but fortunately only one core. It also crashes
once every couple of days on average in its net code (sometimes several
times in a row, sometimes not for weeks). But outside its freezes it
responds without noticeable lag to clicks on folders that donít have
thousands of unread items, and with zero lag to clicks on items Ė so
long as I have it keep all feeds loaded in memory anyway. And so itís
consuming a gigabyte of RAM at this time.

Later versions show the opposite behaviour on this machine. OT1H they
only freeze up for shorter periods, though more frequently. OTOH they
respond with contemplation times ranging from noticeable to lengthy to
any click.

So while 1.2 is very painful all in all, it is tolerable for reading,
whereas later versions work better but are not usable.

(The other machine has only a handful of feeds and items. Performance is
unremarkable no matter the version, and Iíve kept it up to date.)

As always the reminder that the program architecture is build
around a small set of feeds. One can always scale to a point
where it doesn't work anymore, but this doesn't mean that the
implemented architecture doesn't work as it should.

Why stop at 600 feeds? :-)

Cheers
Lars