Insert can be 25% faster, using 28% fewer allocations about go-radix

[pjebs]

Since writing this, have you discovered any issues with your implementation suggestion?

[FrankReh]

No problems. The whole design requires the slice of edges remain in sort order so it makes sense to take advantage of that when adding an edge. And there are lots of examples of go code using the results of sort.Search for inserting and for using copy to create the space needed for the insertion.

Of course it also has to work when the list being added to is empty and it does that too. So no problems.

For those to whom speed really matters, I'll point out that the three places addEdge is called can be further optimized. I've gone with removing the addEdge method completely and using a new insertEdge method that takes the insertion index too because even the binary search in addEdge was unnecessary - in the first usage, the edge list had already been searched and found not to contain the edge - hence the call to addEdge, so I used the result of the getEdge binary search; in the second call to addEdge, the list is known to be empty so I passed an index of 0 to insertEdge, and in the third case, where we know the list of edges is size one, I added the code to test whether the new label was less than or greater than the existing label so could pass an insert index of 0 or 1.

Finally, I later found examples in the go std library where they expanded the call to sort.Search. It is a surprisingly small, easy piece of code, once one has it (one 'for' loop, no recursion), and it can be nice not having to create a closure to perform the binary search when the input is just a slice of bytes and a byte. I don't know if the go compiler will ever be smart enough to optimize that kind of thing away on its own.