Optimize collect

[curlup]

Was

$ go test -bench . -benchtime 4s -benchmem
TieKeys-4        	 1000000	      8335 ns/op	     847 B/op	      67 allocs/op
PrefixSearch-4   	   10000	    617542 ns/op	   71653 B/op	    6287 allocs/op
FuzzySearch-4    	    1000	   8789504 ns/op	  793950 B/op	   52051 allocs/op
BuildTree-4      	      30	 172820241 ns/op	64263468 B/op	  908713 allocs/op
PASS
ok  	_trie	30.907s

And now its

$ go test -bench . -benchtime 4s -benchmem
TieKeys-4        	 1000000	      4583 ns/op	     566 B/op	       7 allocs/op
PrefixSearch-4   	   20000	    219790 ns/op	   33746 B/op	      16 allocs/op
FuzzySearch-4    	    1000	   5759077 ns/op	  479819 B/op	    5065 allocs/op
BuildTree-4      	      20	 240212152 ns/op	78269795 B/op	 1347616 allocs/op
PASS
ok  	_trie	24.888s

It's better than #16, but there's additional memory footprint and time to build trie.

[curlup]

I've improved my result but still building trie takes more time/ops/mem than current impl

$ go test -bench . -benchtime 4s -benchmem
TieKeys-4        	 1000000	      4616 ns/op	     565 B/op	       7 allocs/op
PrefixSearch-4   	   30000	    217131 ns/op	   33710 B/op	      16 allocs/op
FuzzySearch-4    	    1000	   5641379 ns/op	  480559 B/op	    5065 allocs/op
BuildTree-4      	      30	 188456008 ns/op	70782355 B/op	 1011021 allocs/op
PASS

[derekparker]

This function does not seem to be used anywhere.

[derekparker]

We might be able to get the same speedup and greatly reduce allocations by using the string builder.

[jsign]

We might be able to get the same speedup and greatly reduce allocations by using the string builder.

I did another PR to optimize collect and now see this one.
In particular, there I do use string builder as you mentioned... might be useful to mix both ideas maybe.

[derekparker]

Merged via another PR.