We don't use this type anywhere else, and given that ResourceViewModel can be frequently updated (health checks, wait for, state, etc) a frozen dictionary doesn't seem like a good choice. There is probably more overhead in creating it vs a regular dictionary than time saved looking up its properties in an optimized fashion.
PR changes the type to immutable dictioanry.
Checklist
Is this feature complete?
[x] Yes. Ready to ship.
[ ] No. Follow-up changes expected.
Are you including unit tests for the changes and scenario tests if relevant?
[ ] Yes
[x] No
Did you add public API?
[ ] Yes
If yes, did you have an API Review for it?
[ ] Yes
[ ] No
Did you add <remarks /> and <code /> elements on your triple slash comments?
[ ] Yes
[ ] No
[x] No
Does the change make any security assumptions or guarantees?
[ ] Yes
If yes, have you done a threat model and had a security review?
[ ] Yes
[ ] No
[x] No
Does the change require an update in our Aspire docs?
Description
I noticed FrozenDictionary showed up in profiling while I was fixing a memory leak - https://github.com/dotnet/aspire/pull/6666
We don't use this type anywhere else, and given that ResourceViewModel can be frequently updated (health checks, wait for, state, etc) a frozen dictionary doesn't seem like a good choice. There is probably more overhead in creating it vs a regular dictionary than time saved looking up its properties in an optimized fashion.
PR changes the type to immutable dictioanry.
Checklist
<remarks />and<code />elements on your triple slash comments?Does the change require an update in our Aspire docs?
breaking-changetemplate):doc-ideatemplate):Microsoft Reviewers: Open in CodeFlow