First Run is slow

Question

First Run is slow

JeffBusterCase opened this issue 3 years ago · 12 comments

First Run is slow

Answer 1 · 2022-03-13T14:10:26.000Z

Hi. thanks for the comment.

In most cases, we can only choose one of first-run speed and post-run speed on a managed platform.
However. using ILEmit instead of Expression can shorten the first run time a bit.
But this will need an overhaul of the entire library.

I'll try it tomorrow.

Answer 2 · 2022-03-13T16:35:10.000Z

Maybe adding a Initialization? I don't know if this is possible.... Before a project is run.?

Answer 3 · 2022-03-14T09:30:24.000Z

Maybe adding a Initialization? I don't know if this is possible.... Before a project is run.?

I think it can't be a solution.
You just moved that 1ms to elsewhere but it won't change the fact that it took 1ms.

Answer 4 · 2022-03-15T00:40:22.000Z

This one displays the ~~sad~~ gap even more:

Answer 5 · 2022-03-15T01:19:36.000Z

This one displays the ~~sad~~ gap even more:

Can you provide the source code so I can reproduce this?

Answer 6 · 2022-03-15T02:05:36.000Z

Here:
https://github.com/JeffBusterCase/BenchmarkFastNewManually

Answer 7 · 2022-03-15T02:42:43.000Z

Here: JeffBusterCase/BenchmarkFastNewManually

Thanks. I see the code and I think there are some issues with the measuring.

First, you shouldn't benchmark them in parallel.
It's because two or more threads can be assigned to the same CPU core and they will be certainly slower than others.
You should benchmark them one by one instead.

And you should use Stopwatch instead of DateTime.

Stopwatch automatically checks for the existence of high-precision timers.
It is worth mentioning that DateTime.Now often is quite a bit slower than DateTime.UtcNow due to the work that has to be done with timezones, DST and such.
DateTime.UtcNow typically has a resolution of 15 ms. See John Chapman's blog post about DateTime.Now precision for a great summary.

https://stackoverflow.com/questions/28637/is-datetime-now-the-best-way-to-measure-a-functions-performance

It's recommended to use Benchmark.NET
https://benchmarkdotnet.org/articles/overview.html

Answer 8 · 2022-03-15T03:20:15.000Z

I updated the code to better match the correct benchmark, but still... the initialization is what kills the objective :(
https://github.com/JeffBusterCase/BenchmarkFastNewManually

On the last 2 lines:
FastNew[NoInit] takes 8x times more time than Common (The two of them on 60k iterations)

Answer 9 · 2022-03-18T06:51:19.000Z

This issue is delayed to 3.2.0 due I found a solution that better than ILGenerator.
#19

Answer 10 · 2022-03-22T08:28:43.000Z

Solved in #19
you can enable FastGenericNew.SourceGenerator to call GetActivationInfo by adding this to the project file

<PropertyGroup>
    <FastNew_AllowUnsafeImplementation>true</FastNew_AllowUnsafeImplementation>
</PropertyGroup>

Answer 11 · 2022-03-22T10:24:50.000Z

Sorry, I didn't understand.. Shouldn't this be a 'official' fix instead of a workaround/option.....
How can I test on my project witthout the Nuget Version (Still on 3.1.0-preview)

Answer 12 · 2022-03-22T11:22:25.000Z

Sorry, I didn't understand.. Shouldn't this be a 'official' fix instead of a workaround/option..... How can I test on my project witthout the Nuget Version (Still on 3.1.0-preview)

This is an 'official' fix. the new implementation is stable now after working on it.
You can see how this library work now by checking the generated code: https://github.com/Nyerst/FastGenericNew/tree/main/FastGenericNew/_generated/FastGenericNew.SourceGenerator/FastGenericNew.SourceGenerator.Generator

The reason why this is an option is that it's slower than the classic FastNew
which defeats the purpose of this library

v3.2.0 is not released yet because there are still some minor jobs for the Unit Test project to do.
For now, you can try v3.2.0 by cloning this repo and compiling it.
Note that you will need .NET 7 SDK to compile this library.

You can reproduce the Benchmark by running the FastGenericNew.Benchmarks project.