Consider optimisations of async configuration hotpaths for synchronously-provided results

[reisenberger]

It seems reasonable that the delegates used to configure async MonkeyPolicy instances allow users to provide an async lambda. This permits users make async calls to consult some config source, for the enabled toggle, the injectionRate, or indeed what Exception, TResult, TimeSpan is going to be injected in fault scenarios. Currently the signatures we provide for such delegates are of the form Func<..., Task<bool>>, Func<..., Task<double>>, Func<..., Task<Exception>>, Func<..., Task<TResult>> etc.

That said, many (perhaps even a majority) usages might be sync. Simmy offers overloads taking constant values. Even for config-driven cases, it might be preferable for looking up the config to be a rapid in-memory check, with new values being pushed into that in-memory store by some other process (callback/monitor) when the underlying config source changes.

We want users to be able to include MonkeyPolicy in prod/whatever systems with minimal perf impact on executions, so want to optimise to minimise allocations and execution time.

Propose: Consider the use of ValueTask<>. Refs;

• Stephen Toub blog
• Szymon Kulec blog
• SO question with eminent contributions from eg Eric Lippert and Stephen Cleary

[mebjas]

This is great. I'll look into this one. Is there a way to do a benchmark test on some small sample to have measurable perf impact on large / small load and maybe automate it with each deployment - some known Github tooling?

[vany0114]

@mebjas do you mean a benchmark tool? if so, maybe we can use this one

Benchmark idea is great.