Use top-k sorted list builder instead of full-list sorts in search indexes.

[isoos]

• SDK search index improvements (tracking issue) #8670 and Package search index improvements (tracking issue) #8671
• updated _rankWithValues to not build a full list and initialize the result objects lazily
• local benchmark showed 3-5% latency improvements in the most common queries (offset=0, limit=10 for packages), which somewhat linearly disappeared as offset increased to the total item counts (as expected)
• added another check that prevents sorted list building if offset is larger than the maximum expected result count

[sigurdm]

I don't think this is a binary tree insertion, but insertion in a sorted list, complexity O(n*k) (the insertion step is linear in k)

[isoos]

Ah, good point, I was ignoring the List insertion step, as in the comparison was dominating the sorting times much more. However, the reduced gain on high-k values may be due to the List insertion. I was certainly lazy in the insertion part, will take a look how to improve it.

[sigurdm]

You could use an actual binary tree (though that comes with its own overhead)

If k is small enough, simple list insertion might be better

[sigurdm]

Also, if we stick with the list, consider using https://pub.dev/documentation/collection/latest/collection/binarySearch.html . Binary search is known as being notoriously hard to implement correctly

[isoos]

In this case the implementation is very close to the one in package:collection, but I will certainly benchmark it, and if it about the same, we shall use it:
https://github.com/dart-lang/core/blob/main/pkgs/collection/lib/src/algorithms.dart#L47-L62

[isoos]

binarySearch in this case is not usable, as it returns -1 when the searched item is not in the collection, while this algorithm needs the index where the next item should be inserted into. Furthermore, in most of the cases there is no equality, it won't be in the collection. However, with close review, I don't think the algorithm is conceptually the same, except for this specific goal.

I've checked List.insert + List.removeLast() (if the list is over k) and overall did perform worse.

[isoos]

Since we know both k and N upfront, we could probably decide which sorting is more worthwhile: this top-k list building for low k or a full list + single sort upfront otherwise. (We could also limit k, e.g. the number of text search results to 1000 or some reasonably high number).