Optimize Path#relative_to?

[HertzDevil]

Path#relative_to? calls #/ to build up the final path successively. This is done for each path component, which means the whole method has quadratic complexity. Only a single #join is necessary here and reduces the complexity to linear.

[straight-shoota]

Path#join(Enumerable) still results in a sequence of individual join calls to construct the final path.
So it doesn't seem this change would really improve much. It just introduces an intermediary array.

We know all parts are well-formed and they have no separators at either end. So we could probably use a String::Builder here and trivially concatenate the parts. We do that in #normalize already.

[straight-shoota]

Now it makes more sense 👍
I'm still wondering if a string builder wouldn't be better. With the array, we know the exact size of the string and don't need to reallocate the string buffer. But that comes at the cost of allocations for the array itself.
If we could calculate a good estimation for an upper bound of the string size, the string builder should be more efficient.

[straight-shoota]

Regardless of further improvements, this seems like a nice, low hanging fruit.
Of course we could do even much more by stepping through the original paths (non-normalized) directly, without iterators. Could also memcpy the trailing part of target_path.