Quote:
Originally Posted by phil_ga
If you search via the search bar (thats why its there huh??) it takes 5 seconds for some authors and 30 or more for others (with a program appearing to freeze in between). The same searches mostly take the same time: eg danielle steel is 5 seconds, yet jon sprunk is more than 30. Its all very unsatisfying. I only search via typing in the search bar.
|
Typing naked words on the search bar means "search in every column for that word". Thus, typing "jon sprunk" means search for "jon" in every column then search for "sprunk" in every column . This would explain some slowness, but certainly not all.
You can speed this up by limiting the columns to search when using naked search terms. See Preferences -> Searching. My guess is that not searching the comments field will do wonders for you.
Quote:
|
Please simply believe me when i say its calibre - not my pc
|
Sorry, but no can do. I once spent a week (many hours of my time) working with someone making the same claim, only to discover that there was some daemon running that ate the processor. The person thought that it didn't matter.
You might be right (and probably are), but then again possibly not. Clearly there is something different between what you see and what many other people see.
Quote:
|
I remain with the feeling that its the size of the db file that is the problem...but I cannot be sure.
|
The size of the DB is related to the amount of stuff in memory. However, as I said, the DB is not used during searching (I wrote this code and can guarantee it), so it is an indirect relationship.
Quote:
|
Can any one answer about the conditions under which opf files are actually saved to disk? I bet never, until you do the backup manually (about 5 hours for my library).
|
They are queued to be written whenever metadata changes. They are actually written sometime later, when their point in the queue arrives (I wrote this code as well). That 'sometime' is usually within seconds, but can be much longer if you just changed 10,000 books.