Add KV try get

[mtmk]

KVBench.cs:

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Gen1	Allocated	Alloc Ratio
TryGetAsync	150.3 us	2.87 us	2.95 us	0.89	0.02	0.2441	0.2441	4.5 KB	0.82
GetAsyncNew	170.5 us	3.33 us	3.56 us	1.01	0.03	0.2441	-	5.78 KB	1.05
GetAsync	168.3 us	2.82 us	2.50 us	1.00	0.02	0.2441	0.2441	5.49 KB	1.00

TryGet is performing much better.

the new Get (which is using TryGet) is slightly worst because of the additional async/await state machine I'm guessing.

cc @srs-adamr @to11mtm

• see also Exception Usage Harms Performance - Proposed Solutions #581

[srs-adamr]

Looks good!

[to11mtm]

I'll give this a look tonight @mtmk

[to11mtm]

the new Get (which is using TryGet) is slightly worst because of the additional async/await state machine I'm guessing.

Async await and Delegate state captures are very interesting. AFAIR for example, if you've got multiple anonymous delegates (e.x. myList.Where(a=> a.Foo == this.CaptureOne).Where(a=>a.Bar== captureBar).Where(a.FooBar == captureFooBar)) the compiler may prefer to re-use the same 'capture' type between instances (i.e. it's not re-using instances, but it keeps number of compiler generated types down), so your delegates can allocate more memory. In extreme cases, splitting synchronous logic out into separate calling methods was sometimes useful, both for this and to save on locals.

[to11mtm]

I'm OK with it, My biggest concern would be my comments about EnsureSuccess and how to use, since that method would be exposed API.

The other stuff can be handled via future PR if needed, but hopefully is good food for thought for possible perf/mem improvements

[to11mtm]

More comments

[to11mtm]

Reviewed general cleanup, looks awesome!

[scottf]

LGTM