FHIR Chat · Setting Code properties is slow · dotnet

Stream: dotnet

Topic: Setting Code properties is slow

Michele Mottini (Nov 05 2019 at 23:24):

            var patient = new Hl7.Fhir.Model.DSTU2.Patient();
            var watch = Stopwatch.StartNew();
            const int count = 10_000;
            for ( var i = 0; i < count; i++ )
            {
                patient.Gender = Hl7.Fhir.Model.AdministrativeGender.Female;
            }
            watch.Stop();
            Console.WriteLine( "Set code X {0:N0}: {1:N1} msec", count, watch.ElapsedMilliseconds );

Michele Mottini (Nov 05 2019 at 23:24):

Output: Set code X 10,000: 62.0 msec

Michele Mottini (Nov 05 2019 at 23:26):

(for non-code properties the time is < 1 msec)

Michel Rutten (Nov 06 2019 at 08:37):

Property setters raise the PropertyChanged event. Did you hook up a subscriber?

Brian Postlethwaite (Nov 06 2019 at 10:47):

I'd expect it's the try parse enumeration stuff. But without using the profiler couldn't be sure.
Would be a good example to try with the dotnet profiler.

Brian Postlethwaite (Nov 06 2019 at 10:48):

Also, the optimizer with a native property might optimizer things out, but can't be sure.

Michele Mottini (Nov 06 2019 at 14:20):

The slowness comes from GetAttributeOnEnum() (https://github.com/FirelyTeam/fhir-net-common/blob/develop/src/Hl7.Fhir.Support/Utility/ReflectionHelper.cs#L219) - that is called every time

Michele Mottini (Nov 06 2019 at 14:24):

I created an issue https://github.com/FirelyTeam/fhir-net-api/issues/1169

Brian Postlethwaite (Nov 10 2019 at 20:35):

Any suggestions @Michele Mottini there is also the mirror property element that has the string representation in it, which is what is going on there, converting the enum to the string representation.

Brian Postlethwaite (Nov 10 2019 at 20:35):

We could generate a hash table I guess.

Michele Mottini (Nov 10 2019 at 23:47):

Yes, hash tables is the way to go

Christiaan Knaap (Nov 11 2019 at 09:27):

I see a PR coming :-)

Brian Postlethwaite (Nov 12 2019 at 03:32):

I was thinking about them more, and from a generation perspective, a switch/case function would be better, though that then can't be extended with other values, but that isn't the issue with the current stuff anyway. code vs data - where it sits in memory...

Michele Mottini (Nov 26 2019 at 23:35):

Turns out that there is already a cache - it is just a matter of using it: https://github.com/FirelyTeam/fhir-net-common/pull/16

Last updated: Apr 12 2022 at 19:14 UTC