optimize decomposing clip calls

[tcql]

trafficstars

Because clipping with GH means decomposing to pairwise clip calls, there's a lot of looping and array modification in some of the operations. This can result in very slow operations when you have complex inputs, such as very large multipolygons.

I think we could optimize this a lot by doing some checks before looping over and clipping shapes multiple times. For instance, I think we could detect whether two shapes are touching in advance, and maybe even keep an internal index of shape relationships internally so consecutive internal GH calls won't have to do lots of useless legwork.

[mourner]

Looking at the code, I think the biggest optimization you can make is getting rid of pretty much ALL array cloning, slicing and splicing. Given that you convert arrays to linked lists in the GH call itself, you can refactor the code in such a way so that you convert rings once outside and then operate them without the need to do needless copy of data.

[tcql]

:+1: I was just talking to @morganherlocker about this the other day. I'm also pretty sure that in the current state, cloning is not necessary for most of the operations anyway, so this should definitely clean stuff up & give some perf boost