Quelques questions sur le site appel DLR cache

Question

Veuillez me corriger si ma compréhension de la méthodologie de résolution de fonctionnement de DLR est erroné

DLR a appel quelque chose que la mise en cache du site d'appel. Étant donné "a + b" (où a et b sont tous deux des entiers), la première fois, il ne sera pas capable de comprendre l'opérateur + (plus) ainsi que l'opérande. Donc, il va résoudre les opérandes, puis les opérateurs et sera mis en cache au niveau 1 après avoir construit une règle appropriée. La prochaine fois, si un type de correspondance similaire est trouvé (où l'opérande est de type entiers et l'opérateur est de type +), il va regarder dans le cache et retournera le résultat et désormais les performances seront améliorées .

Si cette compréhension de la mine est correcte (si vous tombiez que je me trompe dans la compréhension de base de rectification de bien vouloir), j'ai les questions ci-dessous pour lesquelles je suis réponse à la recherche

a) What kind of operations happen in level 1 , level 2 
    and level 3 call site caching in general 
    (i mean plus, minus..what kind) 

    b) DLR caches those results. Where it stores..i mean the cache location 

    c) How it makes the rules.. any algorithm.. if so could you please specify(any link or your own answer) 

    d) Sometime back i read somewhere that in level 1 caching , DLR has 10 rules, 
level 2 it has 20 or something(may be) while level 3 has 100. 
If a new operation comes, then I makes a new rule. Are these rules(level 1 , 2 ,3) predefined? 

    e) Where these rules are kept? 

    f) Instead of passing two integers (a and b in the example), 
     if we pass two strings or one string and one integer, 
     whether it will form a new rule? 

Merci

Answer 1

a) Si je comprends bien, tous les niveaux fonctionnent actuellement de la même manière: ils exécutent un délégué qui teste les arguments importants pour la règle, puis exécute une opération ou note l'échec (l'échec est noté en définissant un valeur sur le site d'appel ou faire un appel de queue à la méthode de mise à jour). Par conséquent, chaque règle fonctionne comme:

public object Rule(object x, object y) { 
     if(x is int && y is int) { 
      return (int)x + (int)y; 
     } 
     CallSiteOps.SetNotMatched(site); 
     return null; 
    } 

Et un délégué à cette méthode est utilisée dans la L0, L1 et L2 caches. Mais le comportement ici pourrait changer (et a changé plusieurs fois au cours du développement). Par exemple, à un moment donné, le cache L2 était un arbre basé sur le type des arguments.

b) Le cache L0 et les caches L1 sont stockés sur l'objet CallSite. Le cache L0 est un seul délégué qui est toujours la première chose à exécuter. Initialement, ceci est réglé à un délégué qui met juste à jour le site pour la 1ère fois. Des appels supplémentaires tentent d'effectuer la dernière opération que le site d'appel a vu.

Le cache L1 comprend les 10 dernières actions vues par le site d'appel. Si le cache L0 échoue, tous les délégués du cache L1 seront essayés.

Le cache L2 réside sur CallSiteBinder. CallSiteBinder doit être partagé entre plusieurs sites d'appel. Par exemple, il devrait y avoir généralement un et un seul classeur de site d'appel additionnel pour la langue en supposant que tous les ajouts sont les mêmes. Si L0 et L1 toutes les règles disponibles dans le cache L2 seront recherchées. Actuellement, la limite supérieure pour le cache L2 est de 128.

c) Les règles peuvent finalement être produites de deux façons. La solution générale consiste à créer un DynamicMetaObject qui inclut à la fois l'arbre d'expression de l'opération à effectuer ainsi que les restrictions (le test) qui déterminent si c'est applicable. Ceci est quelque chose comme:

public DynamicMetaObject FallbackBinaryOperation(DynamicMetaObject target, DynamicMetaObject arg) { 
    return new DynamicMetaObject(
     Expression.Add(Expression.Convert(target, typeof(int)), Expression.Convert(arg, typeof(int))), 
     BindingRestrictions.GetTypeRestriction(target, typeof(int)).Merge(
      BindingRestrictions.GetTypeRestriction(arg, typeof(int)) 
     ) 
); 
} 

Cela crée la règle qui ajoute deux entiers. Ce n'est pas vraiment correct parce que si vous obtenez autre chose que des entiers, il boucle infiniment - donc habituellement vous faites un tas de contrôles de type, produisez l'addition pour les choses que vous pouvez gérer, et produisez une erreur si vous ne pouvez pas gérer l'addition.

L'autre façon de créer une règle est de fournir directement le délégué. Ceci est plus avancé et permet certaines optimisations avancées pour éviter de compiler du code tout le temps. Pour ce faire, vous substituez BindDelegate sur CallSiteBinder, inspectez les arguments et fournissez un délégué qui ressemble à la méthode Rule que j'ai tapée ci-dessus.

d) ANSWERED b)

e) Je crois que c'est la même question que b)

f) Si vous mettez les restrictions appropriées à alors oui (que vous êtes obligé de faire pour les classeurs standard). Comme les restrictions échoueront parce que vous n'avez pas deux entrées, le DLR sondera les caches et lorsqu'il ne trouvera pas de règle, il appellera le classeur pour produire une nouvelle règle. Cette nouvelle règle reviendra avec un nouvel ensemble de restrictions, sera installé dans les caches L0, L1 et L2, puis effectuera l'opération pour les chaînes à partir de là.