I am study the Timsort from this link hackernoon Timsort
There is a statement "Merging 2 arrays is more efficient when the number of runs is equal to, or slightly less than, a power of two. Timsort chooses minrun to try to ensure this efficiency, by making sure minrun is equal to or less than a power of two."
Why "Merging 2 arrays is more efficient when the number of runs is equal to, or slightly less than, a power of two"?
It's for balanced merges in the general/random case (if the given data isn't random but has long natural runs, then minrun and thus the choice for it might not matter much, and the balance depends more on the lengths of the runs than on the number of runs).
In the general/random case you expect to produce runs of exactly minrun elements. Then when the number of runs is a power of 2, you get perfectly balanced merges throughout. If the number of runs is a bit larger than a power of 2, you end up with a very unbalanced merge. If the number of runs is a bit smaller than a power of 2, you get only a little imbalance.
Again, this is (at least mostly) for the general/random case. If you for example have nine natural runs of lengths 800, 100, 100, 100, 100, 100, 100, 100, 100 elements, then you also get perfectly balanced merges throughout, despite the number of runs being slightly larger than a power of 2.
Excerpt from Tim's own description in listsort.txt regarding this choice of minrun:
Because sortperf.py only tries powers of 2, it took a long time to notice
that 32 isn't a good choice for the general case! Consider N=2112:
>>> divmod(2112, 32)
(66, 0)
>>>
If the data is randomly ordered, we're very likely to end up with 66 runs
each of length 32. The first 64 of these trigger a sequence of perfectly
balanced merges (see next section), leaving runs of lengths 2048 and 64 to
merge at the end. The adaptive gimmicks can do that with fewer than 2048+64
compares, but it's still more compares than necessary, and-- mergesort's
bugaboo relative to samplesort --a lot more data movement (O(N) copies just
to get 64 elements into place).
If we take minrun=33 in this case, then we're very likely to end up with 64
runs each of length 33, and then all merges are perfectly balanced. Better!