With the switch to System.Text.Json in #85 we can further improve TimeZoneNames for NativeAOT applications by switching to a source generated TimeZoneData JSON deserializer.
Unfortunately System.Text.Json does not (yet) support init only properties, see https://github.com/dotnet/runtime/issues/58770.
For this draft I went with public setters, but alternatively a parameterized constructor should also work.
When I ran DataBuilder the order of the output changed, which I guess is either due non-stable dictionary sorting or that the CurrentCulture on my machine is a mix of en-US/en-GB and da-DK (reported as en-DK).
I made a quick benchmark on calling TimeZoneData.Load() on .NET6 using Benchmarkdotnet which only focuses on the performance benefits of switching to a source generated JSON deserializer.
With the switch to
System.Text.Json
in #85 we can further improve TimeZoneNames for NativeAOT applications by switching to a source generatedTimeZoneData
JSON deserializer.Unfortunately
System.Text.Json
does not (yet) support init only properties, see https://github.com/dotnet/runtime/issues/58770. For this draft I went with public setters, but alternatively a parameterized constructor should also work.When I ran
DataBuilder
the order of the output changed, which I guess is either due non-stable dictionary sorting or that the CurrentCulture on my machine is a mix of en-US/en-GB and da-DK (reported as en-DK).TimeZoneData.Load()
on .NET6 using Benchmarkdotnet which only focuses on the performance benefits of switching to a source generated JSON deserializer.Some stats on a
TimeZoneNames.NativeAot
application.main:
PR: