Option to speedup Scoped services creation without concurrent Func or Lazy dependencies in object graph

[dadhi]

Scoped service in DryIoc is created via nested lambda Scope.GetOrAdd(id, () => new ScopedX());
Then inside GetOrAdd there is a lock held to ensure that () => new ScopedX() is called only once.
That guarantee ensures the service is created once.

Now, let's imagine the case when it may save us:

class Y {
    public Y(Lazy<ScopedX> x, Z z) { XY = x; }
}

class Z {
    public Z(Lazy<ScopedX> x) { XZ = x; }
}

Now we have a concurrent logic which may access XZ.Value and XY.Value in parallel. In this case, without a lock and lambda, there is a chance to create ScopeX multiple times.

BUT I would presume, that the case is rare and may be known before-hand.
Another option would be that creating a ScopeX multiple time is fine, we need just ensure that we select the same instance to be used further, and another instance is dropped (e.g. first created instance wins).

So we may provide an option to simplify an expression by removing the nested lambda and creating service as Scope.GetOrTrySet(id, new ScopedX()). This option will greatly simplify expression compilation and call stack as well.

Following will do:

var c = new Container(rules => rules.WithSmallerExpressionButNoSingleScopedInstanceCreationGuarantee());

[dadhi]

This issue may help with #27

[dadhi]

Did some related work in #1

[jzabroski]

Isn't the point of TheadLocal<T> so that you don't use Lazy<T> if you know you need state on a specific thread?

I guess there is a narrow use case where you might want to share the T in Lazy across threads, but that seems like a bad idea.

[jzabroski]

Another option is to allow the Registrar to specify the LazyThreadSafetyModeview=netframework-4.7.2 or to build an expression tree for LazyInitialier.EnsureInitialized which builds the computation graph. Right?

[dadhi]

I am not sure I am following you.
The whole goal is to simplify object graph by removing (not needed?) nested lambdas which prolongs compilation and interpretation times.
This main problem is to decide what lambdas are not needed.

Btw, I am not renaming IRegistrator to IRegistrar. It is too much of breaking change for almost no value.

[dadhi]

Ok, feeling dumb but I will try to assign scoped or any the same expressions into variable and use them in global Expression.Block.
For interpretation I will memoize the results of the same expressions, maybe excluding Constant, Convert and other UnaryExpressions.

[jzabroski]

Ok, feeling dumb

My thought was that , as an end user of your library, I may want to "bring my own threading model" so that you don't have to guess as to whether I have concurrent dependencies.

This main problem is to decide what lambdas are not needed.

I was not looking at the problem from this perspective. I was just thinking, how can we remove concurrency altogether.

I will try to assign scoped or any the same expressions into variable and use them in glabal global Expression.Block.

If I understand you, you're doing a compiler writer trick called Single Static Assignment. Effectively, every node in an expression tree is assigned to once, which makes constant folding analysis easier. The big win behind SSA form is it's trivial to determine constant fold opportunities, because every value in the tree is a constant, so you're literally just looking for duplicates to "lift" up to the top of the tree, thereby reducing memory allocations.

[dadhi]

If I understand you, you're doing a compiler writer trick called Single Static Assignment. Effectively, every node in an expression tree is assigned to once, which makes constant folding analysis easier. The big win behind SSA form is it's trivial to determine constant fold opportunities, because every value in the tree is a constant, so you're literally just looking for duplicates to "lift" up to the top of the tree, thereby reducing memory allocations.

Yes, it fits. So much of cool stuff to learn :)
The idea is simple, but for some reason it didn't appear in clear form to me.

[jzabroski]

You're welcome, buddy! I should be thanking you for such a great library. I would trade 99% of the theory I know to be as good an engineer as you.

If you want to learn more about SSA Form, books by Andrew Appel on writing compilers in and for ML are a great resource. He also has a bunch of brilliantly lucid research papers on compiler system design that can be applied to all kinds of non-compiler systems. In particular, he has a technical note on how to bootstrap a compiler which to me is still the gold standard.

[dadhi]

There is also a performance problem to consider when creating a scoped dependencies in the scoped sevice, that can be directly mitigated by using fan-out ImMapArray.

When first created dependency will be added to scoped items ImMap, it effectively will cause to retry the holder sergice creation. Because upper service should be stored in the same items collection.

Having split / slots of items should help cause the dependency and holder can be stored independently.

[dadhi]

As a result, I ended up compiling nested lambdas once.
In interpreter, I could not evaluate expression once and use it results because
it conflicts with the Service reuse. In a sense I am already checking
if service is created for Scoped / Singleton reuse.