Éviter la boxe inutile dans le DLR

Question

Je joue avec le DLR pour mieux le comprendre. Je ne suis pas encore tout à fait familier avec tous ses concepts et sa terminologie tellement désolé pour toute erreur terminologique ou conceptuelle dans ma question. Fondamentalement, la façon dont je le comprends est que vous faites circuler des objets dans les arbres d'expression mais que vous utilisez des classeurs pour exposer la fonctionnalité dynamique de vos objets à d'autres langages compatibles DLR. Ainsi, au lieu de faire un ajout, par exemple, directement dans l'arbre d'expression (Avec expression.Add), vous créez un classeur qui est appelé par le site d'appel chaque fois que cela est nécessaire et fait l'addition pour vous. Cependant, puisque vous passez des objets autour, à la fin de l'opération d'addition (si les opérandes sont, par exemple, deux valeurs Int32) vous devrez encadrer l'Int32 résultant à un objet puisque (toujours dans le classeur) que ce que le site d'appel attend. J'ai un peu peur que cette constante boxe/unboxing affecte quelque peu la performance de l'exécution.

Est-ce vraiment la façon dont il est censé fonctionner (avec tous les boxe/unboxing) ou est-ce que je manque quelque chose?

Answer 1

Dans un langage typé dynamiquement, l'identification et l'optimisation d'une variable typée statiquement est une optimisation spécifique au domaine. Dans l'implémentation d'un langage dynamique particulier X, vous pouvez conserver une variable locale sans boîte dans le code généré, mais dès que vous exposez une API typée dynamiquement, il n'y a aucun moyen de garantir le typage statique (la nature même des langages dynamiques).

Pour éviter la boxe, vous devrez identifier les morceaux de code que vous pouvez prouver les types statiques partout, et générer du code spécialement pour eux soit par Linq.Expressions ou ILGenerator.

Answer 2

En ce qui concerne les reliures, vous pouvez également implémenter un classeur personnalisé. Ce classeur personnalisé peut renvoyer un type autre qu'un objet ou effectuer d'autres optimisations spécifiques. Dans IronPython, nous utilisons la couche externe DLR ComboBinder et ComboActionRewriter pour optimiser les conditions. Par exemple "si a.b:" peut se transformer en un ComboBinder qui fait à la fois le a.b et la conversion en booléen. Si a.b donne un bool non-boxé, nous éviterons la boxe et le déballage. Nous prévoyons d'expérimenter plus d'optimisations comme celle-ci.