However, LightInject's RegisterFallback hack is not quite the same as DryIoc's RegisterDelegate. With DryIoc.RegisterDelegate, the service types (e.g., contractType) are stored in lookups, so when the time come the service type needs to be resolved, the delegate that returns an object for the service type could be determined quickly

Another problem with RegisterFallback is it is called lastly after LightInject determines the type is not registered at all, that could lead to performance problem. There's a good optimization though, once the unregistered type matches a RegisterFallback's condition, RegisterFallback's factory delegate is cached to the unregistered type, making the RegisterFallback's condition not to be evaluated again anymore

Another potential performance problem, the code could be littered with lots of ifs if we want to target specific types, to wit:

However, multiple RegisterFallback could potentially cause a delay on app's cold start especially if there are too many of them. On the positive aspect, once the unregistered type matches a RegisterFallback condition, RegisterFallback's factory delegate is cached to the unregistered object, making the RegisterFallback's condition not to be evaluated again anymore, plus there's no more many ifs inside the factory delegate