Bring everyone over to the subbatch pattern, for consistency.
Bring everyone over to the subbatch pattern, for consistency.

'--word-diff' says it better than I can:

	BenchmarkLatchAllocation                 5000000               [-270-]{+267+} ns/op
	BenchmarkBaseline_JsonUnmarshalling      1000000              2226 ns/op
	BenchmarkLatchTrigger_0Listeners        10000000               187 ns/op
	BenchmarkLatchTrigger_1Listeners         5000000               [-252-]{+257+} ns/op
	BenchmarkLatchTrigger_2Listeners         5000000               [-313-]{+320+} ns/op
	BenchmarkLatchTrigger_4Listeners         3000000               [-459-]{+462+} ns/op
	BenchmarkLatchTrigger_8Listeners         2000000               [-724-]{+728+} ns/op

Yes, the JSON canary test *literally* took the same number of nanos.  It's not actually doing allocation different, so this should be no surprise (it's a nice confirmation that the subbatch isn't damaging to results).

The other trigger tests are similarly unphased and showing minor noise here; this makes sense, because they already weren't allocating in the measured block.  (Though this also seems to, per the recent research, also indicate that GC, which should still be costing less now, simply doesn't phase them.  Which is... it seems believable, knowing how go GC pools things and only introduces barriers where it must, but is nonetheless impression.

Note, in more than a few ways this seems ridiculous; wouldn't it be easier to just communicate to the benchmark driver that we refuse to run more than $N in a batch because We Can't?  But I'm not aware of any way to do that.  AMEND: I can *absolutely* think of a way to do that; you just set `b.N` to the same number every time.  The downer?  Your test is still gonna get called again and agaaaaaain; there's no way to hint to the test/bench tool that we're not going to go higher, so the whole system will just burn silicon for a while until it hits the timeout.

The `-benchtime` flag can be used to reduce stupidity here -- 500ms still shows accurate results, while wasting much less time -- though I still feel like that's kind of a poor stand-in for having a way to declare "no, this test just *won't* be able to represent the same truths over $N runs".

Signed-off-by: Eric Myhre <2346ad27d7568ba9896f1b7da6b5991251debdf2@exultant.us>

polydawn/go-sup,polydawn/go-sup