You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yatagan, as Dagger in fastInit uses "switching providers" mechanism to reduce classloading. This means that for every binding, that can't be created inline (has Lazy/Provider usages) there's an index assigned. And every provider/lazy object instantiates the binding using the index and a lookup (switch) table.
Now, the hypothesis is, that when the lookup table becomes very large, the performance is going to be penalized. Yatagan currently generates plain switch statement, while Dagger did so with only up to 100 objects, after that it generated another switch level with index % 100 labels.
Let's try to investigate and possibly introduce the optimization.
Might be reasonable to do when the performance testing is implemented in #7
The text was updated successfully, but these errors were encountered:
Yatagan, as Dagger in
fastInit
uses "switching providers" mechanism to reduce classloading. This means that for every binding, that can't be created inline (hasLazy
/Provider
usages) there's an index assigned. And every provider/lazy object instantiates the binding using the index and a lookup (switch) table.Now, the hypothesis is, that when the lookup table becomes very large, the performance is going to be penalized. Yatagan currently generates plain switch statement, while Dagger did so with only up to 100 objects, after that it generated another switch level with
index % 100
labels.Let's try to investigate and possibly introduce the optimization.
Might be reasonable to do when the performance testing is implemented in #7
The text was updated successfully, but these errors were encountered: