search

BlueRaja / High-Speed-Priority-Queue-for-C-Sharp

A C# priority queue optimized for pathfinding applications
MIT License
1.15k stars 169 forks source link

Proposal: Add Targets for Other .NET Runtimes Explicitly #57

Open Chris3606 opened 2 years ago

Chris3606 commented 2 years ago

Currently, the NuGet package for this project targets .NET Standard 1.0, as well as a a coulple other .NET framework targets: image

I propose that, in addition to the current target platforms, other .NET targets that implement .NET Standard 1.0, including .NET Standard 2.0, .NET Core 3.1, .NET 5, etc be added explicitly as targets.

Although targeting .NET Standard 1.0 allows the project to be used on any target implementing .NET Standard, targeting the runtimes specifically can, under some circumstances, enable the compiler to apply optimizations that only work for the particular version of .NET being targeted; which may ultimately result in better performance on those platforms even with no actual code modifications. I have not profiled this myself, however; I'm simply leaning on experiences I've had with other libraries.

BlueRaja commented 2 years ago

targeting the runtimes specifically can, under some circumstances, enable the compiler to apply optimizations that only work for the particular version of .NET being targeted

Do you have a source for this? The C# compiler itself does almost no optimizations - nearly all of them are done by the JIT. It would be very surprising if the JIT were holding back optimizations simply because the code was compiled using an older version of .Net Standard.

Chris3606 commented 2 years ago

I have no formal documentation that states it specifically; just some experience with other projects where it appeared that there was some speed increase when the version of .NET being targeted was more specific. C# syntax is not entirely backwards compatible across multiple run-times (at least since the introduction of C# 8; there are features in C# 8 you cannot use when you target versions of runtimes prior to when it was introduced); so it is conceivable that the IL of the compiled library would change for different targets; so it is possible it could be optimized differently. Certainly it's something I recommend you benchmark for yourself for this particular case, if you attempt it at all.

Regardless, (and this may be better as a separate proposal, up to you); I do think it would be ideal if you targeted both .NET standard 2.0 and .NET Standard 1.0 explicitly, even if no other frameworks are targeted. The Microsoft guidance specifically recommends that you have an explicit .NET Standard 2.0 target in order to avoid bloating package graph when you must also target .NET Standard 1.x:

✔️ DO include a netstandard2.0 target if you require a netstandard1.x target. All platforms supporting .NET Standard 2.0 will use the netstandard2.0 target and benefit from having a smaller package > graph while older platforms will still work and fall back to using the netstandard1.x target.