Perf implication of DynamicInjected?

[AndrewSB]

I came here to check something else, and was happily surprised to see the new DynamicInjected wrapper. it solves a problem I faced last year #156

I was wondering -- what are the expected perf implications of using DynamicInjected? I use @Injected properties as instance variables in my SwiftUI views -- those views are structs that get recreated very often.

Would it be a bad idea for me to do a global search-replace for s/@Injected(/@DynamicInjected(/? would I run into more blocks on the main thread as factory resolution happen when those @Injected iVars are used?

[hmlongco]

You're basically asking Factory to resolve an instance every time the property wrapper / view is instantiated anyway. Any performance difference would be negligible.

[AndrewSB]

got it, so it seems preferred to use DynamicInjected whenever one of these properties are only used in a closure action, instead of the view body.

how should i think about factory resolution performance in general? is there locking of the main thread, or priority inversion i should keep in mind, or can i assume they're basically constant time, almost every time?

[AndrewSB]

and if there is some performance impact I should be keeping in mind, is there some way to have the Injected values eagerly evaluate without blocking startup? kind of like async let? so I can preload dependencies at init time without blocking the thread where initialization of my object is happening, with the hope that they're preloaded when the iVar is finally used?

is that already happening internally?

[hmlongco]

Property wrappers are members of the enclosing class or struct, and initialized prior to objection initialization. With Injected resolution occurs on initialization.