carlossanlop on 3.1
Merge in 'release/3.1' changes Merge in 'release/3.1' changes Update dependencies from https:… and 4 more (compare)
I have a System.Text.Json problem. I recently upgraded my API code to .NET 5, and I'm looking into converting the serialization provider from JSON.NET to System.Text.Json. Standard serialization/deserialization works fine, but I'm having trouble converting a particular pattern.
In my API I have a few places where I distinguish between null inputs and undefined in the input JSON. Specifically, null means "remove this value" and undefined means "keep this value as it is".
The way I've implemented this is with the approach described here: https://github.com/alberto-chiesa/SettableJsonProperties. I have a type
Optional<T> which distinguishes between null and undefined, an
OptionalJsonConverter which converts literal null properties to null and omitted properties to undefined, and a custom contract resolver that relies on the ShouldSerialize-metod, as described here: https://github.com/alberto-chiesa/SettableJsonProperties/blob/master/SettableContractResolver.cs.
STJ doesn't have custom contract resolvers (dotnet/runtime#31257, dotnet/runtime#36785 ), nor any sort of equivalent of the "ShouldSerialize" pattern, as far as I can tell. I can't figure out a decent workaround, so I'm basically stuck here. Has anyone else done anything similar?
Can someone please explain what things you guys take into consideration when deciding whether to use
It's used very often in methods that are extremely small and I'd expect the JIT to inline them always but I'm guessing that there are cases where this wouldn't happen without this attribute? perhaps if its called many times in a single method?
I have a method whos code size in IL is 34 bytes that is getting inlined but another simliar one that isnt getting inlined and its IL code size is 30 bytes. So far my conclusion seems to be the JIT is dumb and I should use this attribute in most cases where I want performance.
I need an expert to shime in and please correct me if I'm wrong.
JIT takes a lot more into consideration than just code size
@HaloFour Clearly, that's why I asked when AggressiveInlining should be used.
i'd definitely say jit is very smart
Doesnt seem very smart:
Reset1()method doesnt use anything that is listed in the article given by @jspuij which would 100% prevent the JIT from inlining it.