Eviter la boxe inutile dans DLR

Question

Je joue avec DLR pour mieux le comprendre. Je ne connais pas encore complètement tous ses concepts et sa terminologie, je suis donc désolé de toutes les erreurs de terminologie ou de conception de ma question.

En gros, si je comprends bien, vous transmettez des objets dans des arborescences d’expressions, mais vous utilisez des classeurs afin d’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 des expressions (With Expression.Add), vous créez un classeur qui est appelé par le site d’appel chaque fois que cela est nécessaire et le fait pour vous.

Cependant, puisque vous transmettez des objets, à la fin de l'opération d'addition (si les opérandes sont, par exemple, deux valeurs Int32), vous devrez enchaîner 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 boxe constante / unboxing puisse affecter quelque peu les performances du runtime.

Est-ce vraiment ce qui est supposé fonctionner (avec toute la boxe / unboxing) ou est-ce que quelque chose me manque?

Answer 1

Dans un langage à typage dynamique, l'identification et l'optimisation d'une variable à typage statique est une optimisation spécifique à un domaine. Dans l'implémentation d'un langage dynamique X particulier, vous pouvez conserver une variable locale non encadrée dans le code généré, mais dès que vous exposez une API à typage dynamique, vous ne pouvez plus garantir le typage statique (la nature même des langages dynamiques).

Pour éviter la boxe, vous devrez identifier des morceaux de code pour lesquels vous pouvez prouver des types statiques, et générer du code spécialement pour eux via Linq.Expressions ou ILGenerator .

Answer 2

En ce qui concerne les classeurs, vous pouvez également implémenter un classeur personnalisé. Ce classeur personnalisé peut soit renvoyer un type non-objet, soit effectuer d'autres optimisations spécifiques. En IronPython, nous utilisons les couches externes DLR ComboBinder et ComboActionRewriter pour optimiser les conditions. Par exemple, " if a.b: " peut se transformer en un ComboBinder qui effectue à la fois le a.b et la conversion en bool. Si a.b résulte en un bool non-boxed, nous éviterons la boxe et le déballage. Nous prévoyons d’essayer d’autres optimisations comme celle-ci.