View Single Post
Old 04-15-2011, 04:30 AM   #50
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 11,742
Karma: 6997045
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
OK, I have changes that sort the sublist instead of the entire cache. Before I submit them (they are very small, so Kovid might be able to look at them), a question:

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?
chaley is offline   Reply With Quote