@capink: I think the slowdown is caused by commit "
Template searches should never be cached.". This changes would cause a template search to be re-executed wherever it occurs in the list of saved searches. Before, the cached result would be used even if it was wrong. On the other hand, it would take millions of template searches for this change to cause the delays you are seeing. It is hard to believe that the saved search tree would cause this, but I suppose it is possible if there are thousands of saved searches and all of them run some template search(es) multiple times.
As for running the search on a single book, this should work, although I didn't test it in the actual plugin:
Code:
def is_search_valid(db, search_text):
# search in a vl of only one book for performance
res = True
try:
book_ids = set((db.all_ids()[0],))
except:
book_ids = None
try:
db.new_api.search(search_text, book_ids=book_ids)
except ParseException:
res = False
return res
It will be faster than using the restriction because it avoids running "id=N" on every book in the library.
I don't see any reason why the old code wouldn't limit the query to the single book. The restriction was evaluated before the search, returning a set of candidates (1 book). The saved search query should be run on that one book. Of course, as noted above the "id=N" query is run on every book.