Quote:
Originally Posted by ownedbycats
[...]
This is used in several places; saved searches, column colour/icon rules, action chains templates.
Would performance improve much if I used something like this, that checked the relevant columns directly rather than the composite?
Code:
program:
input = $#kobobookmark;
if
$#booktype == 'Fanfiction'
&& substr(input, 0, 10) == 'OEBPS/file'
&& !$#fanficstatus in 'Anthology,Oneshot'
then
currentchap = re(input, '.*\/file(\d+).*', '\1') - 1;
totalchap = $#chaptercount;
totalchap - currentchap
fi
|
Really hard to say, as it depends on the usage pattern. When doing rules or anything else that nests composite access, the composites are evaluated once per book, then cached. The first use evaluates the composite. Second and later uses see the cached result.
If the composite is used only once then the second approach is faster because the template isn't as complicated. However, the second approach introduces maintenance problems, as you would have two (or more) places that make assumptions about column contents.
Of course, the fastest would be to use a Python template for #chapters. These are as fast as native calibre code.
Note: the composite cache is cleared whenever metadata changes. If you are using these templates in action chains where the chains alter metadata then the cache won't be as effective.