Insert can be 25% faster, using 28% fewer allocations

[FrankReh]

Sorry for the drive by. This is a useful package and I've made extensive changes to my version. There is an easy performance improvement. If you like it, you can take it, no attribution necessary. If not, feel free to close with no further comment.

The numbers I quoted in the header are for benchmarks when 10,000 entries are added to a tree. The order of insertions doesn't matter. They can be ordered, unordered, and even reverse ordered. Always 28% fewer allocations occur.

The package requires the edges are kept sorted. Currently the addEdge method performs a full sort after appending the new edge. Using the same binary search other parts of the package use, the insertion point can be found exactly. The binary search is much more efficient than the sort.

Replace

func (n *node) addEdge(e edge) {
	n.edges = append(n.edges, e)
	n.edges.Sort()
}

with

func (n *node) addEdge(e edge) {
	num := len(n.edges)
	idx := sort.Search(num, func(i int) bool {
		return n.edges[i].label >= e.label
	})

	n.edges = append(n.edges, edge{})
	copy(n.edges[idx+1:], n.edges[idx:])
	n.edges[idx] = e
}

[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.