Prefer strings.Builder over unsafebytes

[diamondburned]

This pull request removes the use of unsafe and instead prefers strings.Builder. This causes a slight performance loss during encoding and none during decoding:

# Old: unsafe
# New: strings.Builder

name          old time/op    new time/op    delta
Encode-8         276ns ±18%     292ns ± 3%  +5.61%  (p=0.010 n=15+15)
EncodeTo-8      1.87µs ± 3%    1.85µs ± 7%    ~     (p=0.056 n=13+15)
Decode-8        3.16µs ± 2%    3.18µs ± 7%    ~     (p=0.784 n=13+14)
DecodeFrom-8    3.74µs ± 4%    3.73µs ± 2%    ~     (p=0.562 n=15+13)

name          old speed      new speed      delta
Encode-8      43.0MB/s ±12%  41.1MB/s ± 3%  -4.38%  (p=0.018 n=14+15)
EncodeTo-8     175MB/s ± 3%   177MB/s ± 6%    ~     (p=0.060 n=13+15)
Decode-8       103MB/s ± 2%   103MB/s ± 6%    ~     (p=0.756 n=13+14)
DecodeFrom-8  87.4MB/s ± 4%  87.7MB/s ± 2%    ~     (p=0.563 n=15+13)

[nihaals]

What's the advantage of avoiding unsafe here? Is there potential UB?

[diamondburned]

No, it's just cleaner. There's just no unsafe.

[nihaals]

I'm unsure, I think performance is an interesting goal, especially with such a small project. Code maintainability isn't a big issue as it would require a very odd implementation for the code to become unreadable or too spaghetti. The only required change I see in the future is #1, other than that, there shouldn't need to be any large changes to functionality or features, so I'm not sure how much of a positive difference this will have (compared to even a fairly small increase of performance).

[diamondburned]

The performance loss was likely because of the preoccupied load on my laptop. A higher sample size would make up for the offset.

[nihaals]

Based on the GitHub Actions log (new, previous):

Previous

BenchmarkEncode-2       	 7240875	       167 ns/op	  71.80 MB/s
BenchmarkEncodeTo-2     	  805804	      1317 ns/op	 248.26 MB/s
BenchmarkDecode-2       	  509618	      2067 ns/op	 158.24 MB/s
BenchmarkDecodeFrom-2   	  427752	      2345 ns/op	 139.46 MB/s

New

BenchmarkEncode-2       	 6624477	       174 ns/op	  68.83 MB/s
BenchmarkEncodeTo-2     	  915034	      1251 ns/op	 261.34 MB/s
BenchmarkDecode-2       	  607250	      2019 ns/op	 161.98 MB/s
BenchmarkDecodeFrom-2   	  564886	      2089 ns/op	 156.51 MB/s

This looks like random variation so I agree, doesn't seem to be a real impact on performance

[nihaals]

Thanks