skip_restore_order

[marco-mariotti]

As per pyranges/ruranges_py#12

Wanted: optional keyword in all methods that internally sort rows as part of their algorithm, e.g. overlap, window_ranges , ... (full list to be determined)

By default, all pyranges methods maintain row order as much as possible.
With skip_restore_order=True (non-default), we don't do such resorting, which provides a speed up.

[endrebak]

restore_order=True is better

I fixed this for overlaps in ruranges at least

[endrebak]

pyranges/ruranges_py@0fe43e2#diff-4dca36aeca7dd3c4ece50626aa5c0b644adbb628a20d7ee4e14a89d97ee0391cR149

I do not see this change as very important though and I do not think there will be much of a speedup for most functions

[endrebak]

I think this is fixed now?

[marco-mariotti]

I understand that ruranges offers this interface, but methods in pyranges are still not taking advantage of it. They should add an optional argument to do so.

Need to edit code and add at least one test in every PyRanges function that adopts this functionality

[endrebak]

I'll fix this soon. Will be a giant change possibly (lots of diffs from doctests) so I'll make it its own commit.

[marco-mariotti]

Hi @endrebak
do you still think that you can take care of this?
summary, adding restore_order (default True) to every pyranges1 method which runs a ruranges method with sort_output
for best speed (and thus in benchmark) we would then have restore_order=False

[endrebak]

I can have a look

[endrebak]

pyranges/ruranges_py#32

will do a pyranges1x commit afterwards

[endrebak]

The above also includes a faster merge (like how that Heng Li software does it and how pyranges used to it)

[endrebak]

#148

[endrebak]

Actually I think the name should be restore_order. I guess sort_output is wrong because if the input is not sorted the output will not be sorted