Avoid allocating channels unnecessarily on map inserts

[peterebden]

We don't always insert, but we were always allocating a new slice just in case we did. This makes it lazy.

I don't love duplicating the Set function but I don't see a great alternative (it also hurts a bit to add the extra non-inlineable function call on every insert when we do have a value).

Before:

INFO: Run 1 of 5
INFO: Complete in 12.06s, using 14470100 KB
INFO: Run 2 of 5
INFO: Complete in 12.64s, using 15571780 KB
INFO: Run 3 of 5
INFO: Complete in 12.14s, using 14686056 KB
INFO: Run 4 of 5
INFO: Complete in 13.47s, using 15443652 KB
INFO: Run 5 of 5
INFO: Complete in 12.06s, using 13783684 KB
INFO: Complete, median time: 12.14s, median mem: 14686056.00 KB

After:

INFO: Run 1 of 5
INFO: Complete in 11.94s, using 14640700 KB
INFO: Run 2 of 5
INFO: Complete in 12.00s, using 13965888 KB
INFO: Run 3 of 5
INFO: Complete in 11.68s, using 14098944 KB
INFO: Run 4 of 5
INFO: Complete in 12.32s, using 15145640 KB
INFO: Run 5 of 5
INFO: Complete in 12.15s, using 14744944 KB
INFO: Complete, median time: 12.00s, median mem: 14640700.00 KB

[toastwaffle]

Should this be s.m[key].Val? IIUC, existing.Val will be zero if existing.Wait is non-nil.

It looks like the existing tests don't actually check the return value of Set (and I question whether it actually needs to return the value at all)

[peterebden]

Set was supposed to return the old value; there'd be no point in returning s.m[key].Val there since that's what the caller supplied.

I think you're right that nothing actually cares about this any more though, so maybe it can all just be simplified out.

[peterebden]

Okay right, I've removed it from Set where it was no longer needed. This now returns whatever is set now which is more useful (the callers of it never look at the value in that code path but it still makes more sense this way).

[toastwaffle]

plz fix lint, otherwise lgtm