23 March 2012

60x Performance Decrease

For everyone wondering about the bad performance when using Liferea on ext4 this is how it looks:

Version Avg Startup Avg Full Update
1.6.7 (ext3) 2,3s 15,8s
1.8.0 (ext3) 2,6s
(VACUUM on startup)
1s
(introduced asyncsqlite)
1.9.1 (ext3) 2,1s
(VACUUM now on demand)
1,1s
1.9.1 (ext4 defaults) 2,2s 59,1s
1.9.1 (ext4 no barriers) 2,1s 1,2s

Test Notes:
  • All tests were performed on the same host with Debian Wheezy the same feed list (and same cache directory for each cache version) and a "echo 3 >; /proc/sys/vm/drop_caches" to get a cold disk. 
  • DB Size was roughly 10MB with 80 feeds and cache size 100
  • The "Avg Startup" column corresponds to the "liferea_shell_create" measurement you get with "liferea --debug-perf". The "Avg Full Update" column is the sum of the costs of all update callbacks as reported by the "feed_process_update_result" callback.

As you can see we have a 60-times decrease in performance with the same code! This causes the GUI to freeze during updates and surely makes Liferea unusable.

2 comments:

Paulo Anes said...

Lars,
I tried to see what was slow during update of all feeds (I'm in Fedora 16 with ext4) and it seems that the delete of old items is very slow.

Just creating (with sqlite3 command line) 2 more indexes:
CREATE INDEX items_idx5 ON items (parent_item_id);
CREATE INDEX items_idx6 ON items (parent_node_id);

was enough to improve the response of liferea (1.8.0) that comes in fedora.

Lars Lindner said...

Paulo Anes: This is a good point. I'll add those indizes the code. Thanks for debugging this! This should solve the slow item removal.