An interesting question is what exactly do you mean by overlap?

For example: for some applications, a subnet that is entirely contained by another:

subnet 1:         S..........E
subnet 2:            S.....E
[download]

Can easily be done away with entirely.

But subnets that overlaps but not completely:

subnet 1:         S..........E
subnet 2:                  S.....E
subnet 3:         S.............E
subnet 4:    S......................E
[download]

Will rarely be able to be coalesced directly into a single subnet (#3), as the 'nearest' subnet that would contain both (#4) will usually also contain addresses not contained in the original set.

And given 50_000 inputs, the likely scenario -- in the absence of more specificity regarding the distribution of the subnets -- is that they will form a tree with a few large, 'root' level subnets each containing a hierarchy of smaller subnets:

   s...................................e s......e         s...........
+....e
     s...............e      s........e     s.e s...........e   s.e s..
+...e
    s......e s....e 
        s......e
[download]

That suggests a strategy whereby instead of sorting the subnets by start/end address, you should sort them by subnet size. The first (largest) therefore will not be contained by any of the others, so can be removed from the list, and used as the root of a tree. It may of course, overlap with one or more of the next few largest, but except for the rare event where the two can be combined into a single, unextended subnet, they will still be roots of their own subtrees.

So my suggestion would be to pick off the biggest ones and remove them from the list very quickly. You can then distribute the rest as subordinate to one (or more) of the roots you picked out. You can then (recursively) process each of those lists, to further divide their lists into smaller third level lists below a few second-level subroots. Rinse and repeat.

Subnets entirely contained within a higher level can be easily discarded.

The initial sorting by subnet size is very fast. And the first level of recursion very quickly splits the dataset into several or many small subsets that are quickly processed at each new level of recursion.

I might have posted code, but I found that testing such is very hard in the absence of a real dataset. Randomly generated datasets are just too random to give meaningful results.