GitLab

It does not.

I turned benchtime up to 15s because in 1s runs, any signal was well
below the threshhold of noise.  And even with larger sampling:

```
BenchmarkFeedGennedMapSimpleKeys-8                      39906697               457 ns/op             400 B/op          5 allocs/op
BenchmarkFeedGennedMapSimpleKeysDirectly-8              39944427               455 ns/op             400 B/op          5 allocs/op
```

It's literally negligible.

It's still possible we'll see more consequential results in the case of
structs, possibly.  But from this result?  I'd say there's pretty good
arguments made *against* having the extra method, here.

(Thank goodness.  Been in theoryland for a while.)

There's somewhat more content here than necessary for the benchmark
that's presently runnable; right now only the Map_K_T implementation
is targetted.  I want benchmarks of things with complex keys in codegen
and also benchmarks of the runtime/generic/free impls soon, so
they can all be compared.

There's also a quick fliff of stdlib map usage in a wee benchmark to
give us some baselines...

And there's also a quick fliff of stdlib json unmarshalling for the
same reason.  It's not fair, to be sure: the json thing is doing work
parsing, and allocating strings (whereas the other two get to use
compile-time const strings)... but it sure would be embarassing if we
*failed* to beat that speed, right?  So it's there to keep it in mind.

Some off-the-cuff results:

```
BenchmarkBaselineNativeMapAssignSimpleKeys-8             6815284               175 ns/op             256 B/op          2 allocs/op
BenchmarkBaselineJsonUnmarshalMapSimpleKeys-8             724059              1644 ns/op             608 B/op         14 allocs/op
BenchmarkFeedGennedMapSimpleKeys-8                       2932563               410 ns/op             176 B/op          8 allocs/op
```

This pretty good.  If we're *only* half the speed of the native maps...
that's actually reallyreally good, considering we're doing more work
to keep things ordered, to say nothing of all the other interface
support efforts we have to do.

But 8 allocs?  No.  That was not the goal.  This should be better.

Time to dig...

We really, truly cannot get away from having a KeyAssembler option.
That much seems clear.  So that's moved up into the interface we're
working with, and one of the alternate drafts dropped.

The comments around the NodeBuilder.Reset method are resolved: the
parts about building keys are removed, as we've concluded pretty
solidly that those were indeed about to take a wrong turn.
(Resetting a builder is still a useful thing overall if you're going
to make a bunch of nodes of a single type: the node allocations
will still happen, but the builder being resettable should be
pretty much a giant duff's device action, and saves one of the
two mega-amortized allocations in a codegen'd world, which is better
than not.)

Dropped the "demo" function.  This isn't the place for it, and that
demo had also gone awry.

Some new questions about some of the other "simple" methods on
MapAssembler and ListAssembler.  Are they useful shortcuts (that
actually provide a performance benefit if present directly on the
assembler interface)?  Or are they trivially recreateable from a
freestanding function operating the interface, and thus better be
done that way, to save SLOC in codegen outputs?

I think I'm going to start needing benchmarks to come to useful
conclusions on that last question pair, so... it's time to move forward
on writing some more implementation code matching these interfaces.
(Unfortunately, I think there's at least... four different
implementations needed to get a good eye on things, since the codegen
path vs runtime fully generic interfaces path have *very* different
characteristics, and then we need each of the styles of interest
implemented for each.  But that's just what we'll have to do.)

This is one of those situations where I'd really, really, really love
to be able to state default values for method params.  And I don't see
who could possibly be hurt by such a language feature, so I'm sad we
don't have it.

Hopefully to become final.  I'm going to try to copy the contents out
to the root dir to become the new interfaces at the end of this.

I copied most of the node.go file and it's probably best to read that
as a diff from the live one.  Mostly, it adds the NodeStyle type
and the documentation around that.

The nodebuilder.go file still devolved into some commentstorms and
incomplete parts, but is probably honing in on minimally-unsatisfying
compromises.

I used a couple symlinks to "copy" the types for Path, etc, from the
live main package, just to get more things compiling together.
Those features aren't showing any cracks and aren't up for review due
to any transitive interactions that are in question, so, this treatment
is sufficient to move things along.

Links aren't present in the package yet.  I may or may not do some
reconsiderations on those to match the "style" naming pattern, as the
'nodestyle' research package already briefly probed; or, it might be
out of scope and something for later (if at all).  This is a presently
a compile error until I handle it one way or the other.

The long-story-made-short of the remaining commentstorm is: handling
map keys generically just absolutely sucks.  There is basically no
way to do it without massive allocation penalties for boxing.  Any and
all alternative tradeoffs I can think of are baroque and not pleasing.
I'm still hoping for another idea to strike, but at this point it's
looking like it's time to bite some bullet (any bullet) and move on.
Signed-off-by: Eric Myhre <hash@exultant.us>