+1 on adding merge_sorted - I've found myself wanting it inside the histogram implementation

The function has the comment

        /*
         * Updating only one of the indices based on the previous key
         * gives the search a big boost when keys are sorted, but slightly
         * slows down things for purely random ones.
         */

The way it works is to do binary search with the modification that the first trial is the last success rather than the center of the whole array. When the keys are sorted, the search range decreases as the keys move upwards.

On adding merge_sorted, the needed code can be taken from the merge_sort implementations.

The way it works is to do binary search with the modification that the first trial is the last success rather than the center of the whole array. When the keys are sorted, the search range decreases as the keys move upwards.

I see so unless I'm missing something this is still a suboptimal speedup -- i.e. it does not reduce the runtime from O(n log n) to O(n). I'm surprised that it still has such a big effect, but maybe because in my example x and y were the same length?

Note that a merge_sorted(a, b) implementation would be O(Na + Nb), whereas search_sorted (without the optimization above is O(Na log Nb). For large Nb, search_sorted is faster than the merge approach.

@charris - For anyone like me misreading your comment, I should clarify that function we're proposing is not "(merge sort)ed" but "merge (sorted)". Clearly that name is suboptimal!

Agreed that the effect is unexpectedly large, my back of the envelope calculation, which may be way off, gives me an expected speedup of ~7%. I'm going to guess what is going on is a pattern of memory accesses that doesn't change much search to search, so cache may come into play. For sorted keys one can also proceed by taking increasingly large jumps upward, followed by binary search.

@eric-wieser The merge sorts do merge_sorted :)

What is actually providing the speedup here is the reduction in branch misses. With this dense list of keys to search the wanted next key is usually very close to the beginning of the remaining search space so the branch results are mostly going the same direction.
As searching is all just comparing and branching, allowing the cpu to correctly predict most branches greatly improves performance.

the optimization of reducing the search space is actually harmful for the unsorted performance here, we knew these cases exist when it was implemented, but at the time the binsearch was also untyped so in total the performance was still better for all cases.
It might be worthwhile to tune this code again a bit for unsorted keys.