Avoid redundant null-checking

[SergeiPavlov]

ResolutionExtensions.TryResolveService() already checks context != null
No need to check for this in any caller.
Each branching has significant overhead in modern CPUs with high pipe-lining.

Also:

• Use ArgumentNullException.ThrowIfNull() instead of direct ifs .
  it is more efficient as explained here: https://dunnhq.com/posts/2022/throw-helper/
  (less of "cold code" would be cached in CPU I-cache)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.73%. Comparing base (b222d0f) to head (a576e40).
Report is 6 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1429      +/-   ##
===========================================
+ Coverage    78.60%   87.73%   +9.12%     
===========================================
  Files          200      200              
  Lines         5716     5682      -34     
  Branches      1160     1143      -17     
===========================================
+ Hits          4493     4985     +492     
+ Misses         712      696      -16     
+ Partials       511        1     -510     

Flag	Coverage Δ
	87.73% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alistairjevans]

The extra-null-check-removal looks fair, but the extra if-defs make it a bunch more complicated.

[alistairjevans]

I don't like adding a load of additional #if blocks like this just to optimise the null check. Can you provide a benchmark with evidence of the gain? It would have to be a pretty big improvement to justify I think.

[SergeiPavlov]

Can you provide a benchmark with evidence of the gain

It will be difficult to model the impact of CPU I-cache pollution on a real application.
Typical benchmarks contain little code and CPU cache is big enough.
And big-code benchmark would have many other, may be volatile, factors

I don't like adding a load of additional #if

There is other way: to write custom ThrowHelper with the same functionality as ArgumentNullException.ThrowIfNull()

[tillig]

We've definitely avoided adding the ThrowIfNull thing in the past simply because the maintenance overhead has outweighed the micro-perf you might get from that helper. I don't think they do this in the core framework libraries, either.

[SergeiPavlov]

I don't think they do this in the core framework libraries

They do this since the beginning of the "Core fork". e.g.
https://github.com/dotnet/runtime/blame/a0e9764708d5781168c22d86ccb7437f1e54a915/src/coreclr/src/mscorlib/src/System/Collections/Generic/Dictionary.cs#L106

This is not exacly .ThrowIfNull(), but the key idea is the same - to extract verbose throw code into separate function to avoid caching it in the CPU

[SergeiPavlov]

Reverted ArgumentNullException.ThrowIfNull() #ifs

Also:

• Removed redundant null-cheking in RegistrationExtensions, ContainerBuilder.UpdateRegistry()/.RegisterCallback()