22 October 2009

Work on 1.8

Just a short note on what we are doing for 1.8. Right now we try to reduce startup time by killing costly cleanup stuff done on startup by cleaning up the DB schema and we are also thinking about a good way to periodically vacuum the database on startup. The problem there is to find a good interval and to avoid doing it too often as it costs time even if the DB is in a 100% clean state.

If you want to test try running SVN trunk which performs a cache migration to the new DB schema. By reducing the schema by one unnecessary table we now skip some consistency checks which sometimes took around 10s of startup time.

If you do test it please post us some comparison values in the comments! You can gather the startup time by launching both 1.6 and trunk using this command:

liferea --debug-db --debug-performance | grep "startup took"

10 comments:

Anonymous said...

Why not vacuum the database when liferea is idling ? In my case, liferea is usually in the background and idling and I enter on it when the tray icon lights.

When you startup liferea you want to start reading news as fast as it's possible, so if it starts vacuum the database it will be slower.

My idea is something like tracker, work when the system is idling.

Bill said...

I seem to be behind in releases (1.4.26 on Ubuntu Jaunty) but if it's worth anything I'm very happy running liferea from a shell script that VACUUMs automatically. Sometime last year this allowed me to get a 5-7 minute (I think; wasn't taking measurements back then) startup time down to 20-60 seconds, and of course the interactive performance improved too.

jell said...

btw. could you try to run liferea under some "white on dark" system theme?

with such settings you could observe some troubles (like in welcome message) - probably in css, where text color is set to some dark value, but background color is leaved for system value (so in dark based theme it looks unreadable).

Lars said...

jell: We often test Liferea's theming with dark GTK themes and have optimized it as far as we believe is possible. There will always be some color combinations not working especially when two of the three usable theme colors are the same (which is often the case).

Gravis said...

there is a serious performance problem when you get a feed that has a lot of entries. even switching to the feed takes 20+ seconds! there is the same issue when doing "mark all as read". additionally, the gui becomes unresponsive, so multithreading should be added. im not sure exactly where the bottleneck is but it needs to be addressed.

Anonymous said...

What about releasing (development) 1.7.2? 1.7.1 seems to me rather old and a bunch of changes were done since then.

proggy said...

I don't really have a speed problem when switching feeds but what strikes me is a noticeable freeze of 5 secs when checking all feeds for updates (1.6.0 on 64 bit Ubuntu 9.10).

Lars said...

@proggy: This is a known issue. When mass updating feeds we are updating so many that the following GUI updates (counter updates, on-the-fly item list merging) along with running the request response handling inside the GTK event handling freezes the GUI.

Adrian Bunk said...

@Gravis:
"switching to the feed takes 20+ seconds" sounds like a problem Lars fixed in 1.7.1

maxbritov said...

I have long switching beetween feeds too. --debug-db show a lot of "DB: removing item with id xxxxxx" on that moment.
I use 1.7.4 now.