Thanks for all your suggestions. I've considered all of them and here's what I found.

Why are $points and $neighborEdges hashrefs mapping integers (as strings) to values?

Big picture implementation: what we are talking about is one method in a larger OO style pm I'm building. $points gets populated elsewhere and it's eaiser to pass this around as a ref. Obvioulsy this isn't apparent in my example. However I really have no reason to keep neighborEdges that way and can change it. Impact here was marginal if any.

but it looks like you don't actually care about the real distance between points. Instead, you care about relative distances. So you can store the square of the distances (by not doing the sqrt) and get the same results.

I do care about the actual distances, but only for those edges I identify as neighboors. So this point is quite valid, I don't really need to sqrt until after I identify these. This isn't going to impact things sine the caculation of the edges takes a second vs 17ish minutes for the intersect loop.

Since Determinant is called so many times, I wonder whether you'd get any improvement over rewriting it without the temporary variables.

Tested, the answer appears to be no.

I'd probably try rethinking SegmentIntersection.

Ahhh! I love coming here and having people see all these things that make perfect send yet never occured to me. Ofcourse! This only has marginal impact. The test data leaves only 2240 Determinant calls out... so 1120 get dropped early.