— Macro: LT_INIT (options) — Macro: AC_PROG_LIBTOOL — Macro: AM_PROG_LIBTOOL Add support for the --enable-shared, --disable-shared, --enable-static, --disable-static, --with-pic, and --without-pic configure flags.1 AC_PROG_LIBTOOL and AM_PROG_LIBTOOL are deprecated names for older versions of this macro; autoupdate will upgrade your configure.ac files.Does anyone reading knows a solution to this problem?
30 March 2012
28 March 2012
25 March 2012
This helps a lot when you use the "Unread" search folder and accidentily skip an item and forgot from which feed it came.
Note: To introduce the new buttons I had to change the stock icon of the "Next Unread Item" button. I decided to change it from the "forward" stock button to the "jump to" stock button which I believe to be a good match.
This feature is planned to be released with 1.9.3
23 March 2012
|FS||Journal Mode||Page Size||Sync Mode||Update Duration|
According to the sqlite documentation WAL journaling is expected to have a significantly better write-throughput compared to synchronous mode without journaling. The results above confirm this.
When using "PRAGMA synchronous=FULL" the execution time improves to 1/10 of the original 60s. With WAL journaling the sqlite documentation recommends to use only "PRAGMA synchronous=NORMAL". By doing so we loose the durability guarantee from the ACID criterias, but 1/60 of the original execution time might be worth it. The sqlite documentation says
"There is a very small (though non-zero) chance that a power failure at just the wrong time could corrupt the database in NORMAL mode."
Additionally the page size is said to have an influence on the performance. This isn't the case for Liferea, but to be on the safe side it doesn't hurt increase from the default setting of 1k to 32k which should cost only a bit more memory.
- As already mentioned the chance of data loss will increase...
- Also sqlite3s WAL journal is not supported on network filesystems!
We have to try to switch to WAL mode.There is no guarantee that it will be safe without long term tests, but the immediate performance gain is critical.
I'll create two releases 1.8.3 and 1.9.2 soon and hope you give a lot of feedback! It would be most helpful if you can include the number of feeds, your cache size setting and DB file size.
|Version||Avg Startup||Avg Full Update|
(VACUUM on startup)
(VACUUM now on demand)
|1.9.1 (ext4 defaults)||2,2s||59,1s|
|1.9.1 (ext4 no barriers)||2,1s||1,2s|
- 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.
What could be the best way to hook dynamic CSS into Webkit? I found no WebkitView properties for setting font and background color which would also be a solution and I want to avoid implementing an internal callback just to load dynamic CSS...
18 March 2012
|Be lazy with cleaning!|
This behaviour was suggested by adriatic in the discussion of a blog post concerning Lifereas performance by Jeff Fortin.
I hope this will easy the pain of the heavy users since most distros moved to ext4. Please give feedback wether this did help you or not!!!