Tim Cassell

Thanks for opening this issue. I was the one who asked about it on that thread. One thing that I'm hesitant about is actually supporting the full engine, since BDN...

All good points. > The non framework compatibility levels only limit the available API surface, so the framework ones can be used here in all cases. But settings like IL2CPP...

Another thing to think about concerning benchmarking Unity APIs is, as it is currently implemented, BDN wouldn't be able to measure any of Unity's AsyncOperations, because those all rely on...

Well there are a lot of build options, and even different options between unity versions. So maybe BDN could allow the user to specify the path to a project settings...

I'm seeing similar weirdness for long-running benchmarks even with the default job: ``` | Method | Job | Runtime | Allocated | |---------------------- |----------- |------------------- |----------:| | AsyncYieldTaskInt | Job-WLKFHY...

I'm guessing you mean when returning `IAsyncEnumerable()` from the benchmark method, it should `await foreach` on the result and measure all the awaits and yields, and pass the `T` yielded...

In that case, this looks like a great candidate for a follow-up to my suggestion for fixing ValueTasks. https://github.com/dotnet/BenchmarkDotNet/issues/1595#issuecomment-778923271 Which is refactoring the engine to use an `IMeasurer` interface instead...

For completeness, this should also include `IAsyncEnumerator`.

I can take this if #2111 gets merged.

I actually ran into this while attempting to measure survived memory in #1596. I ended up adding a `Clear` method that I ran at the end of the benchmark. Unfortunately...