Quote:
Originally Posted by chaley
Without this change, searches operated on the sorted cache. library.caches.search generates a list of IDs, then order that list in the same way as the cache order. Because of this, it is not necessary to sort again after a search. However, if we are sorting the sublist (the search results), then the sort must be redone after every search.
Given that this matters only on a huge library, it isn't clear to me which is better. If searches tend to find large segments of the library, doing the sort again will be slower overall than what it is today. However, if the searches tend to find much smaller segments of the library, sorting the segment is a significant win. I can sort 400 records 100 times before I pay the cost of sorting 40,000 once.
Opinions?
|
What happens when a user clears the search and goes back to viewing all the books? Will that be slower than it is now?
From a search perspective I would have thought optimising for the 99% case of a far smaller search subset and having that displayed faster would be a nice win. I guess the question is "how much" slower is it for very large searches?